1. Introduction

This section will provide you with an overview of the Synchronize Standby Database (also known as the Sync feature) feature in Multiplatform.

This option is to assist in two particular scenarios:

• Resolving unrecoverable archive log gaps

  • This can happen when archive logs were lost or deleted by accident before they were transferred and applied to the standby database.  This way we can roll the standby database forward using RMAN incremental backups, instead of recreating it.  

• Fixing logical corruption on the standby database due to nologging operations that were performed on the primary

  • When nologging operations are performed on a primary database, there is no redo available that can be used to update the standby database.  The effect is logical corruption on the standby database.  

  • We recommend that FORCE LOGGING be enabled for the primary database

The Sync feature, in summary, does the following:

1. Detect the current standby database SCN number

2. Compares this with the Primary database and then starts an incremental backup on the primary for all blocks from this SCN number.

3. The backup process can take a similar time to a full RMAN backup based on the time the standby was out of sync with primary and the changes that happened during the timeframe.

4. The backup should, however, be small - depending on the difference between the primary and standby

5. The backup is then transferred to the standby database server

6. From there a recovery process is started that will use this incremental backup to roll forward the standby database.

7. During this process, the standby controlfile is recreated

2.  Synchronize Standby Database

In the section below we will show you how you can run the Sync feature for both options to recover from unrecoverable archive log gap, as well as fix logical corruption due to nologging operations.

It may happen that an archivelog was removed by backups before it was shipped to the standby, or if the standby database is far behind the primary for some reason - it is then possible to make use of the Synchronize Standby Database feature provided by Dbvisit Multiplatform. This method can be used instead of the traditional rebuild of the standby database using the CSD (Create Standby Database) feature.
During this process, Dbvisit Multiplatform will perform an incremental backup on the primary database backing up the required changed blocks from the SCN number where the standby is currently and then ship this backup to the standby and then use RMAN to recover the standby using this backup. The result is that the standby database is "rolled forward" past this missing archived log. The process is easy and described in the steps below.

Choose the configuration for which you need to synchronise the standby database.

( 1 ) The primary and standby details are displayed including the SCN and timestamp the Primary and standby are at and also the time gap between them

( 2 ) By default, the Synchronize Lag option is selected.

( 3 ) We can use the transportable media option for the destination so that the external media can be used to take backup in source and we could resume the sync once the media has been attached in the standby.

( 4 ) Specify the temporary backup location where the incremental backup will be created on the primary database server. It is important that this location must be able to hold at least a full compressed backup of the primary database (RMAN compressed backupset). If you do not have sufficient disk space, the Synchronize Standby process will fail. Note that the backup in most cases will be much smaller than a normal full backup as only the blocks needed to recover the standby database will be backed up. Make sure this location has correct permission and that the Oracle software owner has full read-write permission on this folder. This is the temporary location on the standby database server where the temporary incremental backup will be copied. It is recommended that this location have sufficient space to hold a full compressed backup of the primary database to ensure you do not run into any space-related issues during this process. This location must exist on the standby database server and the Oracle software owner must have full read/write permission on this folder.

( 5 ) Once you have provided the source and destination temporary backup locations, you can click on start to start the process.

The progress of the synchronize standby can be seen from the tasks .

Once the process is completed, the automatic standby update can be enabled and the archivelogs would automatically be shipped from primary and applied on standby.