2. Take a note of current System Change Number (SCN) on the standby database using
the following SQL statement:
SQL> SELECT current_scn FROM V$DATABASE;
3. Perform an incremental RMAN back up and create a new standby control file on the
primary database:
$ export ORACLE_SID=<primary database SID>
$ rman target /
RMAN> BACKUP INCREMENTAL FROM SCN <value from the above query>
DATABASE FORMAT /u00/tmp/incr_db_%U;
--- create a new standby control-file
RMAN> backup current controlfile for standby format
/u00/tmp/standby.ctl;
4. Copy the files generated under the /u00/tmp directory to the same location on the
standby database site. You can use any copy/FTP option to transfer the backup files
from primary to the standby database site.
5. Once files are moved/copied on the standby site, execute the following sequence of
commands on the standby database:
$ rman target /
RMAN> shutdown database;
RMAN> startup nomount;
Note: the above step is necessary as the location of the primary and standby data files
are likely to be a different one.
RMAN> switch database to copy;
6. Once the recovery is completed on the standby database, re-create the standby redo
logs and restart the MRP on the standby database using the following SQL statement:
For 10g database:
SQL> alter database recover managed standby database disconnect from session;
4. From RMAN, started the standby instance in mount state and restored the standby
control-file from the location where the file was copied.
SQL> shutdown immediate;
SQL> EXIT
$ rman target /
RMAN> startup nomount
RMAN> restore controlfile from /home/oracle/newstandby.ctl;
RMAN> alter database mount;
5. Restored those two new data files that were created during the standby database
creation time, using the following RMAN scripts:
RMAN> RUN
{
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=hostname,NB_ORA_POLICY=BACKUP_POLICY_NAME,NB_ORA_SERV=nbmaster';
restore datafile 58,59;
RELEASE CHANNEL ch00;
}
Note : The example uses Symantec NetBackup script to restore the data files from the
daily incremental backups stored in the TAPEs. The files were backed-up as part of
the daily incremental backup schedule. Hence, I dont need to take a new backup of
those data files in order to restore them on the standby database.
6. Since the primary and standby data files locations are different, had to catalog the
standby data file location and switched to the database copy subsequently.
RMAN> CATALOG START WITH
+DG_DISKGROUP/STANDBY/DATAFILE;
RMAN> SWITCH DATABASE TO COPY;
7. After switching the database data files to STANDBY data file location, I have
initiated the standby database recovery using the following RMAN script:
RMAN> RUN
{
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=hostname,NB_ORA_POLICY=BACKUP_POLICY_NAME,NB_ORA_SERV=nbmaster';
recover database delete archivelog;
RELEASE CHANNEL ch00;
}
Note : The above script restores required incremental/archive logs from the previous
backups and applies on the standby database to cover the gap. Oracle is smart enough
to sense the current and starts applying the changes from the current SCN onwards.
8. Once the recovery completed, the following error was reported, which is expected
one:
Conclusion
The method and approach demonstrated in this paper can be used in any
standby database environment to cover the huge gap between the primary and
standby. Additionally, if you come across situation like my case, also, it would be
very useful to address the gap or missing data files issues. This approach also
explained how to make use of the backups stored in TAPES.
http://www.toadworld.com/platforms/oracle/w/wiki/10481.a-slightly-differentapproach-to-roll-forward-standby-database-procedure.aspx