PART 1 :- RMAN with Oracle Data Guard in Oracle Database 10g

INTRODUCTION
==================
Data Guard enables and automates the management of a disaster recovery solution for Oracle databases located on the same campus or across the continent. Data Guard consists of a production database (also known as the primary database) and one or more standby database(s), which are transactionally consistent copies of the production database. As transactions occur in the primary database, redo data is generated and is written to the local redo logs. Data Guard automatically transfers this redo data to the standby sites and applies it to the standby databases, synchronizing them with the primary database


RMAN and Data Guard are part of the integrated Oracle High Availability technology stack, RMAN backups can be seamlessly offloaded to a physical standby database, allowing customers to gain more value out of their disaster recovery investment. Backups do not impact normal Data Guard operation – they can be taken while the standby database is in recovery or read-only mode. Backups can be used to recover either primary or standby database servers
 
Data Guard and RMAN are both fully supported features of the Oracle Database Enterprise Edition (RMAN is also provided with Oracle Database Standard Edition).
 
The assumptions for this setup are :-




•The standby database is a physical standby database and backups are only taken on the standby database.


•The data file directories on the primary and standby database are identical.This simplifies the RMAN backup and recovery operations no matter which host is used.


•RMAN Recovery Catalog is required so that backups taken on one database server can be restored onto another database server. Using just the control file as the RMAN repository is not sufficient, as the primary database will have no knowledge of backups taken on the standby database.


•Primary database does not use Oracle Managed Files (OMF). When using OMF, standby database filenames can vary from those on the primary. Refer to the Appendix for modifications to the restore procedures when standby database filenames are different than those on the primary.


Recommended Oracle Database Configuration
    On primary and standby databases:


• Configure Flash Recovery Area :-
     Configure the Flash Recovery Area, by setting the following init.ora
parameters:


DB_RECOVERY_FILE_DEST = <mount point or ASM Disk Group>
DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>


•Use a system parameter file (SPFILE) so that it can be used with any database in the Data Guard configuration. This allows restoring of the SPFILE from a backup taken on another database.



•Uniquely name archived log and backup directories for each database.


For example, on a primary database named ‘PROD’, archived logs are written to ‘/arch/PROD’ directory, whereas on a standby database named ‘STDBY’, archived logs are written to ‘/arch/STDBY’ directory. This allows RMAN maintenance commands, such as CROSSCHECK and DELETE, to be used with the LIKE option to select the appropriate archived logs for a particular database.


•Uniquely tag backups,


 If backups are taken on primary and standby databases. For example, primary database full backups can be tagged ‘BOS_FULL_BACKUP’, while standby database full backups can be tagged ‘SF_FULL_BACKUP’. This allows for proper selection of backups that were taken on a particular database when performing RMAN maintenance operations.



•Enable Flashback Database on primary and standby databases.


When Flashback Database is enabled, Oracle maintains flashback logs in the Flash Recovery Area. These logs can be used to ‘rewind’ the database back to an earlier point in time, without requiring a complete restore.