Dataguard · Oracle · RMAN

Correct SCN on Standby Database

There are many documents that explains how to resolve a gap on the standby database using rman incremental backups. It is pretty useful when you do not want to ship and apply all the missing archive logs to refresh standby database. Recently I had such problem on a new dataguard. My problem was not the size of the missing archive logs that I need to ship and apply. The archive logs were missing on the primary system. Instead of restoring the archivelogs from the tape I prefer to use incremental backup from the primary database.
But It did not work for me. Later I realized that I was calculating wrong scn on standby. Restore time of the datafiles on standby was 4 days before the standby controlfile that I use. When I use the “select current_scn from v$database;” to calculate the scn It gave me the scn on the control file which was pretty close to the primary. But scn on the datafiles was 4 days ago. When I used the scn on the datafiles I was successfully restored the incremental backup and my problem was resolved.

MOS doc :
Steps to perform for Rolling forward a standby database using RMAN Incremental Backup. (Doc ID 836986.1)

How it works :
1 – Determine latest scn on the dataguard. this must reflect the scn on the datafiles so it is better to use x$kcvfh table (take the minimum SCN from the below queries)

SQL> select current_scn from v$database;

-- If no READ ONLY Tablespaces/datafiles in database use 
SQL> select min(fhscn) from x$kcvfh;

-- If READ ONLY tablespaced/datafiles in database use
SQL> select min(f.fhscn) from x$kcvfh f, v$datafile d
	  where f.hxfil =d.file#
		and d.enabled != 'READ ONLY' ;

2 – Take incremental backup on the primary database from that scn


3 – Ship the incremental backup to the standby location (scp , ftp or aircargo 🙂 whatever you like )

4 – Catalog the backup on the standby database

RMAN> CATALOG START WITH '/standby_archive/incrback/';

5 – Stop the recovery on the standby database


6 – Restore the standby database using the cataloged incremental backup


2 thoughts on “Correct SCN on Standby Database

  1. I was curious to know why you prefer an incremental backup from the primary over restoring archived logs from tape? In my experience, as soon as RMAN is done restoring archived logs from tape to the primary, Data Guard ships them to the standby automatically where they are applied immediately (if apply lag is set to 0).

    I will say that, sometimes, it doesn’t work; and I then restore the standby with the incremental backup. I do try to restore the archived logs first, however, because it’s quick and easy.


    1. Thanks for your comment.
      For restoring archive logs you need extra space on the server. To get incremental backup you need space too. So according to disk space they might be even.

      You need to get the incremental backup from the production system and It will put unnecessary load on the production system. Restoring from the tape I think there will be no load on the production database. So tape is superior in this case.

      To transfer the incremental backup you need manual work. For archive log shipping as you said no manual intervention is necessary. Tape wins one more time 🙂

      In my case I wanted a quick solution and I didn’t want to bother the system administrators for restoring the archive logs. Also My incremental backup was pretty small so it wasn’t a big deal for me.

      Thank you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s