Oracle actively promotes the offloading of workload from the primary database to what would otherwise be a completely passive standby database. The suggestions for what to offload include reporting and backup tasks. This paper specifically focuses on taking backups from a physical standby database. The trigger for this work was a discussion in the office about taking backups from a physical standby. The sticking point was that some members of the team were of the belief that there are problems with using backups generated from a physical standby database to recover the primary database. Logic told me that the relationship between a primary database and its physical standby databases would mean that there should be no problems. A physical standby database is, in my mind at least, an image copy of the primary that is being updated with the transactions from the primary database via the redo stream. Anyway, it was time for some testing My Data Guard test system was built using Oracle VM Server and Oracle Enterprise Linux with Database 10g server templates. This made getting a system ready to test was pretty straightforward. The initial tests I conducted were to use an RMAN catalog in order to take backups from both the primary and standby databases. This gave me an insight into how backups from primary and standby databases work. The important points for me were: Providing the catalog is available to both primary and standby, both databases are aware of backupsets and copies regardless of which database they are created on. If you use RMAN to delete backupsets or copies from a node other than the one they are created on an error will be reported, as the files do not exist on the local filesystem. If a backupset is taken from a standby database then that backup set will be known to the primary database through the catalog. This means that the backupset pieces from the standby can be used for restores on the primary providing they are moved to the catalogued location on the primary. After the initial tests I attempted to use backupsets and copies taken from the physical standby database on the primary. This worked without problems and I reported my successes the following morning The challenge then became a little more restrictive, No, not using a recovery catalog. Oh, I m talking about with 9i. And, the database must be in managed recovery mode. So, with the new rules of engagement I set about my task. My logic was that without a recovery catalog I would need to use the CATALOG command in order to make RMAN (via the controlfile) aware of the backupsets or copies. The restriction of 9i meant that I could not use backupsets. So, the plan was: Martin Nash ORAganism 2009 Page 1 of 6
1. Use BACKUP AS COPY on the standby database 2. Remove a datafile from the primary 3. Copy the appropriate RMAN copy to the primary host 4. CATALOG the DATAFILECOPY on the primary host via RMAN 5. RESTORE the missing data file 6. RECOVER the newly restored data file 7. Open database And, this is what happened. Starting standby database on node 2... [oracle@dg02 ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.4.0 - Production on Fri Apr 10 10:19:08 2009 10:19:08 @> conn / as sysdba Connected to an idle instance. 10:19:16 SYS@dg10g> startup nomount ORACLE instance started. Total System Global Area 612368384 bytes 2085872 bytes 180358160 bytes Database Buffers 423624704 bytes Redo Buffers 6299648 bytes 10:19:25 SYS@dg10g> alter database mount standby database; Database altered. Elapsed: 00:00:09.70 10:19:45 SYS@dg10g> alter database recover managed standby database disconnect from session; Database altered. Elapsed: 00:00:07.03 10:20:22 SYS@dg10g> select process, status from v$managed_standby; PROCESS STATUS --------- ------------ ARCH CONNECTED ARCH CONNECTED MRP0 WAIT_FOR_LOG Elapsed: 00:00:00.00 10:20:42 SYS@dg10g> Starting primary database on node 1... [oracle@dg01 ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.4.0 - Production on Fri Apr 10 10:21:25 2009 10:21:25 @> conn / as sysdba Connected to an idle instance. 10:21:30 SYS@dg10g> startup ORACLE instance started. Total System Global Area 612368384 bytes 2085872 bytes 184552464 bytes Martin Nash ORAganism 2009 Page 2 of 6
Database Buffers Redo Buffers Database mounted. Database opened. 10:22:25 SYS@dg10g> 419430400 bytes 6299648 bytes Showing contents of RMAN repository on node 1... [oracle@dg01 ~]$ rman target / Recovery Manager: Release 10.2.0.4.0 - Production on Fri Apr 10 10:25:23 2009 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: DG10G (DBID=3174575825) list backupset; using target database control file instead of recovery catalog list copy; specification does not match any archive log in the recovery catalog Showing contents of RMAN repository on node 2... [oracle@dg02 ~]$ rman target / Recovery Manager: Release 10.2.0.4.0 - Production on Fri Apr 10 10:25:16 2009 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: DG10G (DBID=3174575825, not open) list backupset; using target database control file instead of recovery catalog list copy; specification does not match any archive log in the recovery catalog Switching Logfile on node 1 10:27:06 SYS@dg10g> alter system switch logfile; System altered. Elapsed: 00:00:07.11 10:27:52 SYS@dg10g> Watching it being received on node 2 10:27:23 SYS@dg10g> select process, status from v$managed_standby; PROCESS STATUS --------- ------------ ARCH CLOSING ARCH OPENING MRP0 WAIT_FOR_LOG RFS RECEIVING 6 rows selected. Elapsed: 00:00:00.00 10:27:49 SYS@dg10g> Martin Nash ORAganism 2009 Page 3 of 6
Backing up datafile 1 from the standby... backup as copy datafile 1 format '/home/oracle/backup/%u.rman'; Starting backup at 10-APR-2009 10:32:15 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy input datafile fno=00001 name=+data/dg10g/datafile/system.272.682766427 output filename=/home/oracle/backup/data_d-dg10g_i-3174575825_ts-system_fno-1_1akc44pg.rman tag=tag20090410t103215 recid=25 stamp=683807601 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:15 Finished backup at 10-APR-2009 10:33:31 Starting Control File and SPFILE Autobackup at 10-APR-2009 10:33:31 piece handle=+data/dg10g/autobackup/2009_04_10/s_683807266.331.683807613 comment=none Finished Control File and SPFILE Autobackup at 10-APR-2009 10:33:38 Confirming that RMAN on node 1 is not away of the copy list copy; List of Archived Log Copies Key Thrd Seq S Low Time Name ------- ---- ------- - -------------------- ---- 125 1 67 A 10-APR-2009 10:21:52 +DATA/dg10g/archivelog/2009_04_10/thread_1_seq_67.284.683807227 127 1 68 A 10-APR-2009 10:27:04 +DATA/dg10g/archivelog/2009_04_10/thread_1_seq_68.283.683807275 Crashing ASM instance on node 1 in order to remove datafile 1... ASM is aware that the RDBMS instance is accessing the datafile, so will not let it be removed. Performing a STARTUP FORCE on the ASM instance will shutdown abort the RDBMS instance and allow the datafile to be removed from within ASM. It has been pointed out that simply shutting down the RDBMS instance would have the same effect of allowing the removal of the datafile from ASM. [oracle@dg01 ~]$. oraenv ORACLE_SID = [dg10g]? +ASM [oracle@dg01 ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.4.0 - Production on Fri Apr 10 10:34:59 2009 10:34:59 @> conn / as sysdba Connected. 10:35:04 SYS@+ASM> startup force ASM instance started Total System Global Area 130023424 bytes 2082208 bytes 102775392 bytes ASM Cache 25165824 bytes ASM diskgroups mounted 10:35:24 SYS@+ASM> exit Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0-64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Removing datafile 1 on node 1 [oracle@dg01 ~]$ asmcmd -p ASMCMD [+] > ls data/dg10g/datafile SYSAUX.279.682752985 SYSTEM.281.683806229 Martin Nash ORAganism 2009 Page 4 of 6
UNDOTBS1.278.682752907 USERS.280.683476541 ASMCMD [+] > rm data/dg10g/datafile/system.281.683806229 ASMCMD [+] > exit [oracle@dg01 ~]$ Attempting to start database on node 1... [oracle@dg01 ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.4.0 - Production on Fri Apr 10 10:40:19 2009 10:40:19 @> conn / as sysdba Connected to an idle instance. 10:40:23 SYS@dg10g> startup ORACLE instance started. Total System Global Area 612368384 bytes 2085872 bytes 184552464 bytes Database Buffers 419430400 bytes Redo Buffers 6299648 bytes Database mounted. ORA-01157: cannot identify/lock data file 1 - see DBWR trace file ORA-01110: data file 1: '+DATA/dg10g/datafile/system.281.683806229' 10:40:40 SYS@dg10g> Copying data file copy backed up on node 2 (standby) to node 1 [oracle@dg02 ~]$ scp backup/data_d-dg10g_i-3174575825_ts-system_fno-1_1akc44pg.rman dg01:./backup/ oracle@dg01's password: data_d-dg10g_i-3174575825_ts-system_fno-1_1akc44pg.rman 100% 610MB 38.1MB/s 00:16 [oracle@dg02 ~]$ Catalog the copied data file on node 1 (primary)... catalog datafilecopy '/home/oracle/backup/data_d-dg10g_i-3174575825_ts-system_fno- 1_1akc44pg.rman'; cataloged datafile copy datafile copy filename=/home/oracle/backup/data_d-dg10g_i-3174575825_ts-system_fno- 1_1akc44pg.rman recid=36 stamp=683808283 Restore data file 1 on node 1 (primary)... restore datafile 1; Starting restore at 10-APR-2009 10:45:20 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=151 devtype=disk channel ORA_DISK_1: restoring datafile 00001 input datafile copy recid=36 stamp=683808283 filename=/home/oracle/backup/data_d-dg10g_i- 3174575825_TS-SYSTEM_FNO-1_1akc44pg.rman destination for restore of datafile 00001: +DATA/dg10g/datafile/system.281.683806229 channel ORA_DISK_1: copied datafile copy of datafile 00001 output filename=+data/dg10g/datafile/system.281.683808321 recid=37 stamp=683808398 Finished restore at 10-APR-2009 10:46:46 Recover data file 1 on node 1 (primary)... Martin Nash ORAganism 2009 Page 5 of 6
recover datafile 1; Starting recover at 10-APR-2009 10:46:53 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:03 Finished recover at 10-APR-2009 10:46:57 Open database on node 1 (primary)... alter database open; database opened Confirm database role 10:47:39 SYS@dg10g> select database_role from v$database; DATABASE_ROLE ---------------- PRIMARY Elapsed: 00:00:00.19 10:47:59 SYS@dg10g> Confirm that node 2 is still in managed recovery mode... 10:48:26 SYS@dg10g> select process, status from v$managed_standby; PROCESS STATUS --------- ------------ ARCH CLOSING ARCH CLOSING MRP0 WAIT_FOR_LOG Elapsed: 00:00:00.00 10:48:28 SYS@dg10g> select database_role from v$database; DATABASE_ROLE ---------------- PHYSICAL STANDBY Elapsed: 00:00:00.01 10:48:41 SYS@dg10g>... I think that proves that you do not need to use a RMAN catalog, you can use Oracle 9i commands only and you do not have to stop managed recover in order to use the backups taken from a standby database in order to recover a primary. OK, there are some restrictions. Well, there is one restriction that seems pretty important: the fact that you cannot CATALOG backupsets in 9i. But, that has gone in 10g. So, that s another reason to upgrade. Obviously there are many factors to consider before moving all backups from the primary site to a physical standby and I would be very interested to hear from people who have encountered problems using a physical standby to perform their backups. Martin Nash ORAganism 2009 Page 6 of 6