This action shows how to renew the standby control file in a Data Guard environment with OMF.
$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.bkp
is generated under the $ORACLE_HOME/dbs
directory. This file will be used to restore the standby control file in the standby database.
scp
or ftp
protocols:scp $ORACLE_HOME/dbs/standbyctl.bkp standbyhost:/tmp/standbyctl.bkp
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
$ 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 rm
command on the shell or on asmcmd
respectively.
NOMOUNT
mode:$ sqlplus / as sysdba SQL> STARTUP NOMOUNT
$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
RMAN> ALTER DATABASE MOUNT; database mounted released channel: ORA_DISK_1
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 CATALOG
and SWITCH
commands 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;
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.
clear logfile
statement in the standby database so that they will be created automatically (the log_file_name_convert
parameter 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.
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.