Scribd
Upload
14 views

How to Recover archive gaps in standby database

Uploaded by

awsmdrajiv
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
14 views

How to Recover archive gaps in standby database

Uploaded by

awsmdrajiv
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

How to Recover archive gaps in standby database - using 2

methods

Oracle Golden Gate DBA at Associate @JP Morgan chase

August 26, 2016

Using Both Methods

1. Manually Log Shipping (when the missing logs are very less approx
400)

2. Performing Incremental Backup (When there is a very huge gap)

METHOD 1:

When the logs missing or corrupt is less in number (say below 15), we can
ship the logs which were missing in the standby site from the primary site
(scp/sftp/ftp) and then we can register the log file in the standby so that
the gap can be resolved.

This is easy process if you have missing or corrupt logs in lesser number.

Otherwise we can use the incremental backup strategy, and perform the
recovery at standby site.

Lets go through the Archive log Shipping process

First, Find the archives which are missing by issuing the following
command. This would give the gap sequences

SQL> select * from v$archive_gap

Or you can use the v$managed_standby view to find where the log apply
stuck.

SQL> select sequence#,process,status from v$managed_standby;

Now, Copy the logs to the standby site from the primary site

Using the below command

$ scp
log_file_name_n.arc oracle@standby:/log/file/location/log_file_name_n.arc

At standby site, Do the log file registration at the standby site until all the
missing log files are registered, Use this below command.
SQL> alter database register logfile '/log/file/location/log_file_name_n.arc';

Now apply would take place and your standby will become sync with the
primary.

METHOD 2 :

when the difference is huge (say around 500 logs) the above method is
very time consuming and not a proper approach. Else you have to rebuild
the standby database from scratch.

As an enhancement from 10g, an incremental backup created with


BACKUP INCREMENTAL... FROM SCN can be used to refresh the standby
database with changes at the primary database since the last SCN at
Standby and then managed recovery can resume.

Step 1:

Use this below command to find the SCN difference, on both the database
– Primary DB & Standby DB

SQL> select current_scn from v$database;

Step 2 :

Stop the managed standby apply process:

SQL> alter database recover managed standby database cancel;

Step 3:

Now Shutdown the standby database

SQL> shut immediate

Step 4:

On the primary, take an incremental backup from the SCN number where
the standby has been stuck:

RMAN> run {

allocate channel c1 type disk format '/u01/backup/%U.bkp';

backup incremental from scn ********* database;

Step 5: On the primary, create a new standby controlfile and copy this file
to standby side:
SQL> alter database create standby controlfile as
'/u01/backup/for_standby.ctl';

$ scp * oracle@dataguard : /u01/backup

Step 6 :

Bring up the Standby instance in nomount mode:

SQL> startup nomount

Step 7

Now, replace the previous controlfile with this new one created at
primary , and Bring the database to MOUNT state.

(Because, this Primary Side control file has the information of the SCN and
we have to perform the recovery using this controlfile)

SQL> alter database mount standby database;

Step 8 :

Open the RMAN prompt and Catalog the backup piece.

(Because , RMAN does not know about these files yet; so you must let it
know – by a process called cataloging)

$ rman target=/

RMAN> catalog start with '/u01/backup';

Step 9 :

Recover these files:

RMAN> recover database;

Step 10 :

After performing the recovery , exit RMAN and start managed recovery
process:

SQL> alter database recover managed standby database disconnect from


session;

Step 11 :

Again Check the SCN’s in primary and standby to make sure that both are
in SYNc:

SQL> select current_scn from v$database;

You might also like