RECOVER DATBASE USING SERVICE (Refresh standby database in Oracle 12c)

Before 12c if one of the standby database goes out of sync with respect to the primary database we have to perform the below steps in order to make the standby in sync with the primary.

  • Check the current of the SCN of the standby database from where recovery needs to be done.
  • We need to take the incremental backup of the primary database from that SCN obtained from the standby database.
  • Copy the backup from primary to the standby and catalog the backups
  • Cancel the MRP of the standby database and apply the backup from the primary
  • Create a new control file for the standby database from the primary and mount the standby using the new control file.
  • Start the managed recovery of the standby database.

In 12c, the method remains the same, but it has been made easier. We can use the RECOVER DATABASE USING SERVICE to sync the standby database with the primary.

The command does the same as described above in the background creates incremental backups containing the changes in the primary database. All changes to datafile on the primary database starting with the SCN in the standby data file header all are included in the incremental backup then the backup will be transferred over the network to the standby location and the incremental backup will be applied to the standby database.

Below are the details which we will use:

Primary Database

Standby Database:

There are few prerequisites before we start the activity for 12c

  • There should be Oracle net connectivity between standby and primary which can be done by adding the TNS entry in the tnsnames.ora file of the standby database.
  • This only work for oracle 12c or higher version of the database so the COMPATIBLE parameter should be set to 12 or the higher version.
  • Check the space on the standby database location make sure we have enough space on the server.

Place the standby database in mount Mode:

Checking if Managed Recovery is running on the standby

CHECK WHETHER REDO APPLY ACTIVE

By executing the above command if the BLOCK# is keep on changing the redo apply is active and database will be in sync with the primary, if the BLOCK# remain the same we need to do the recovery.

We can check the sync by using the command archive log list on both primary and standby and comparing the current log sequence no. If there is no difference, we are good else we need to sync the standby database with the primary by executing the below steps on the standby database.

Check SCN of the Standby database

This will be used in later steps.

Connect to the RMAN to refreshes the standby database using the service name

Below is the sample output:

At this point the standby will be in sync with the primary but the control file of the standby database contains the old values of SCN so to complete the synchronization. We need to refresh the control file from the primary database.

Report schema will do an implicit crosscheck and catalogued the files in the recovery area.

If the directory structure of the primary and standby database is different you will get the below alert while performing the above steps

RMAN-06139: WARNING: control file is not current for REPORT SCHEMA

Report of database schema for database with db_unique_name  VASHISHTH

To rectify perform the below steps:

We need recover the standby database before opening in read only mode :

If we open the database now and start the managed process, we will get the below alert in the alertlog

RFS[4]: No standby redo logfiles available for thread 1

So, we need to drop the standby redo logs and recreate them

Open the standby database in read only mode and start the recovery managed process

The standby database will be in sync with primary database now. Which can be checked using archive log list or using

Amit Vashishth
Author: Amit Vashishth

Leave a Reply

Your email address will not be published. Required fields are marked *