This action shows how to renew the standby control file in a Data Guard environment with OMF.
- In the primary database, create a backup of the standby control file with the following RMAN statements:
$rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Wed Dec 19 22:18:05 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1319333016) RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT 'standbyctl.bkp'; Starting backup at 19-DEC-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=149 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including standby control file in backup set channel ORA_DISK_1: starting piece 1 at 19-DEC-12 channel ORA_DISK_1: finished piece 1 at 19-DEC-12 piece handle=/u01/app/oracle2/product/11.2.0/dbhome_1/dbs/standbyctl.bkp tag=TAG20121219T221811 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 19-DEC-12
You'll see that a file named
standbycf.bkpis generated under the$ORACLE_HOME/dbsdirectory. This file will be used to restore the standby control file in the standby database. - Copy this backup file from the primary database to the standby site by using the
scporftpprotocols:scp $ORACLE_HOME/dbs/standbyctl.bkp standbyhost:/tmp/standbyctl.bkp - Query the current online and standby logfile paths in the physical standby database:
SQL> SELECT * FROM V$LOGFILE WHERE TYPE = 'ONLINE'; GROUP# STATUS TYPE MEMBER IS_ ------ ------ ------ ----------------------------------------- --- 3 ONLINE /u01/app/oracle2/datafile/ORCL/redo03.log NO 2 ONLINE /u01/app/oracle2/datafile/ORCL/redo02.log NO 1 ONLINE /u01/app/oracle2/datafile/ORCL/redo01.lo NO SQL> SELECT * FROM V$LOGFILE WHERE TYPE = 'STANDBY'; GROUP# STATUS TYPE MEMBER IS_ ------ ------- ---- ------------------------------------------ --- 4 STANDBY /u01/app/oracle2/.../o1_mf_4_85frxrh5_.log YES 5 STANDBY /u01/app/oracle2/.../o1_mf_5_85fry0fc_.log YES 6 STANDBY /u01/app/oracle2/.../o1_mf_6_85fry7tn_.log YES 7 STANDBY /u01/app/oracle2/.../o1_mf_7_85fryh0n_.log YES
- Shut down the standby database and delete all the online and standby logfiles:
$ sqlplus / as sysdba SQL> SHUTDOWN IMMEDIATE $ rm /u01/app/oracle2/datafile/ORCL/redo0*.log $ rm /u01/app/oracle2/fra/INDIA_PS/onlinelog/o1_mf_*.log
Depending on whether you use the filesystem or the ASM to store the database files, you must run the
rmcommand on the shell or onasmcmdrespectively. - Start up the physical standby database in the
NOMOUNTmode:$ sqlplus / as sysdba SQL> STARTUP NOMOUNT
- On the standby server, connect to RMAN and restore the standby control file from the backup file:
$rman target / RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/standbyctl.bkp'; Starting restore at 19-DEC-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=1 device type=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 output file name=/u01/app/oracle2/datafile/INDIAPS/control01.ctl Finished restore at 19-DEC-12
- Mount the standby database as follows:
RMAN> ALTER DATABASE MOUNT; database mounted released channel: ORA_DISK_1
- If OMF is not being used, and the datafile paths and names are the same for both the primary and standby databases, skip this step and continue with the next step.
At this stage, in an OMF-configured Data Guard environment, the physical standby database is mounted, but the control file doesn't show the correct datafile names because it still contains the primary database's datafile names. We need to change the datafile names in the standby control file. Use the RMAN
CATALOGandSWITCHcommands for this purpose:RMAN> CATALOG START WITH '/oradata/datafile/';For ASM, use the following commands:
RMAN> CATALOG START WITH '+DATA1/MUM/DATAFILE/'; RMAN> SWITCH DATABASE TO COPY;
- If the flashback database is
ON, turn it off and on again in the standby database:SQL> ALTER DATABASE FLASHBACK OFF; Database altered. SQL> ALTER DATABASE FLASHBACK ON; Database altered.
- If standby redo logs exist in the primary database, we only need to execute the
clear logfilestatement in the standby database so that they will be created automatically (thelog_file_name_convertparameter must already be set properly):SQL> SELECT GROUP# FROM V$STANDBY_LOG; GROUP# ---------- 4 5 6 7 SQL> ALTER DATABASE CLEAR LOGFILE GROUP 4; Database altered. SQL> ALTER DATABASE CLEAR LOGFILE GROUP 5; Database altered. SQL> ALTER DATABASE CLEAR LOGFILE GROUP 6; Database altered. SQL> ALTER DATABASE CLEAR LOGFILE GROUP 7; Database altered.
If standby redo logs don't exist in the primary database, the following query will not return any rows. In this case, we need to create the standby redo logs manually:
SQL> SELECT GROUP# FROM V$STANDBY_LOG; no row selected SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 SIZE 50M; Database altered. SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 SIZE 50M; Database altered.
- Start a media-recovery process in the physical standby database. The online logfiles will be cleared automatically.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
We've successfully changed the standby control file using the primary database as a source. With a new standby control file, some database information such as the size and number of the temporary files and the size and number of the online redo logs, will be updated in the physical standby database. These infrastructural changes are not replicated to the standby databases automatically. So if we don't apply these changes manually in the standby database, a new standby control file will fix these inconsistencies.