RMAN in Data Guard Configuration

RMAN in Oracle Data Guard configuration works very normal like single standalone database. But, there are few important things you should know in order to define your backup and recovery strategy when using RMAN with data guard.

Need not register standby with catalog, RMAN will identify it as standby. Catalog is must and this helps primary to be aware of standby backups

• Backup Controlfile on Primary

• Register Primary Database

• Test Archivelog Deletion Policy

• Recover Datafile From Standby

Backup Controlfile on Primary

Backup controlfile on primary and On standby the controlfile is a standby controlfile. In case of primary crash, you cannot use standby controlfile. So, at least backup controlfile and spfile on primary

CONFIGURE CONTROLFILE AUTOBACKUP ON

Set proper retention policy and this will not delete backups for the specified recovery window

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

You can backup archive logs on both primary and standby. This will provide you archive logs redundancy but not recommended.

Register Primary Database

Let us register primary database with catalog

On primary:
===========
rman target / catalog rman_rc/rman_rc@rcat
RMAN> register database;

List db_unique_name on both primary and standby via below command

On primary:
===========
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

On standby:
===========
rman target / catalog rman_rc/rman_rc@rcat
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

Define connection string for the primary and standby

rman target sys/sys@proddb catalog rman_rc/rman_rc@rcat

RMAN> configure db_unique_name proddb connect identifier 'proddb';
RMAN> configure db_unique_name proddb_st connect identifier 'proddb_st';

Resync catalog

RMAN> resync catalog from db_unique_name all;

See how LIST and REPORT command can help you get output from primary and standby

RMAN> list backupset for DB_UNIQUE_NAME proddb;
RMAN> list backupset for DB_UNIQUE_NAME proddb_st;
RMAN> report schema for DB_UNIQUE_NAME proddb;
RMAN> report schema for DB_UNIQUE_NAME proddb_st;

Test Archivelog Deletion Policy

While we configured physical standby, we had already set archive deletion policy to not delete any archive until they are applied on standby

rman target sys/sys@proddb catalog rman_rc/rman_rc@rcat

RMAN> configure archivelog deletion policy to shipped to all standby;

Stop MRP on standby

On standby:
===========
SQL> alter database recover managed standby database cancel;

Generate more archives on primary, run below command few times

On primary:
===========
SQL> alter system switch logfile;

Now, try deletion archives via RMAN. Observer the error message

rman target sys/sys@proddb catalog rman_rc/rman_rc@rcat

resync catalog from db_unique_name all ;
delete archivelog all;

Enable MRP on physical standby, run archive deletion again and this time it should work fine

On standby:
===========
SQL> alter database recover managed standby database disconnect;

rman target sys/sys@proddb catalog rman_rc/rman_rc@rcat

resync catalog from db_unique_name all ;
delete archivelog all;

Recover Datafile From Standby

You can use standby database to restore lost data files. Let us simulate an error with users tablespace

On primary:
===========
sqlplus / as sysdba
select name from v$datafile;
alter database datafile '+DATA/proddb/datafile/example.266.941366921' offline;

Delete above datafile from asm file system as grid user

On primary:
===========
su - grid
asmcmd
ASMCMD> cd data/proddb/datafile
ASMCMD> cp example.266.941366921 example.266.941366921.orig
ASMCMD> rm example.266.941366921
ASMCMD> exit

Restore the datafile from standby. The restored file will take a different name

On primary:
===========
rman target sys/sys@proddb catalog rman_rc/rman_rc@rcat

RMAN> restore datafile '+DATA/proddb/datafile/example.266.941366921' from service proddb_st;

Get the new file name for the restored datafile and recover it

recover datafile '<new_file_name>';

Take the datafile online on primary

SQL> alter database datafile ‘<new_file_name>’ online;