Synchronize a Standby Database using Batch Mode

Owned by Anton Els (Deactivated)
Last updated: Jan 14, 2015
10 min read

The process to synchronize the standby database can be run in 3 ways:

 

  1. Using the Command Line Interface (CLI) using the setup menu 
  2. Using the Web Based User Interface (GUI)
  3. Using the command line batch process

 

This section will provide an overview on how you can perform batch processing options to perform a synchronize of the standby database.  

Running the Syncrhonize Standby Database option is to recover from an unrecoverable archive log gap, where archive logs were lost before they could be applied to the standby database or when nologging operations causing logical curruption on the standby database was performed on the primary database.  This option can also be used if there is a large gap between the primary and standby databases as in some cases running this process is faster to get the standby database up to date (before continuing with normal dbvisit standby database running - sending/applying of logs).


Batch Command:

dbvisit_setup --sync --ddc <DDC> --tmp_dir <tmp_dir> --tmp_dir_dest <tmp_dir_dest> [--sync_lag] [--sync_nologging] [--web] [--output_dir]


Example Command:

./dbvisit_setup --sync --ddc DEV1 --tmp_dir /usr/tmp/ --tmp_dir_dest /usr/tmp/ --sync_lag --sync_nologging

 

The command can be broken down into the following:

OptionDescription
--sync This is telling the Dbvisit Setup to start the Synchronize Standby Database option (additional parameters are required)
--ddc DEV1 

Specify the DDC file to run the Sync process for, in this case the DEV1 DDC file is specified

--tmp_dir /usr/tmp/

The temporary directory on the Primary Server where the Incremental RMAN backup will be stored. This location must be big enough to keep the incremental backup that is going to be performed by this process

In this example, the database is small and the /usr/tmp/ location is specified

Depending on the size of the database and the amount of changes, incremental backups size may vary.

Note that the incremental backup on the primary database can take the same amount of time as a full backup, but only the changed blocks (blocks required to bring the standby database up to date) will be backed up.

--tmp_dir_dest /usr/tmp/ 

The tmp_dir_dest is the location on the standby server where the incremental backup will be copied to. This location as with the tmp_dir location on the primary, must be big enough to keep a copy of the incremental backup.

Depending on the size of the database and the amount of changes, incremental backups size may vary.

--sync_lagThis parameter is specified to tell the dbvisit setup sync process to syncronize the standby database with the primary database - required parameter
--sync_nologgingThis parameter is required if you want to recover standby database datafiles where "nologging" operations were detected. If nologging operations were performed on the primary database, there is no redo to be applied to the standby database which will case "logical" corruption on the standby database. Using this option is recommended.

 

 

Example - Batch process in a Single Instance environment

The command below is an example of running the Synchronize Standby Database option on a Single instance database called rawdb to bring a standby database up to date with the primary.

From the example, we can see that the standby was at sequence 65 where the primary is already at sequence 107.  

 

oracle@dbvlin502[/usr/dbvisit/standby]: ./dbvisit_setup --sync --ddc rawdb --tmp_dir /usr/tmp/ --tmp_dir_dest /usr/tmp/ --sync_lag --sync_nologging
=============================================================
dbvisit_setup started in BATCH mode at 20150113 21:15
csd            =
ddc            = rawdb
restart        =
template       =
output_dir     =
web            =
ddr            =
INTERFACE_MODE = BATCH
=============================================================
./dbvisit_setup --sync --ddc rawdb --tmp_dir /usr/tmp/ --tmp_dir_dest /usr/tmp/ --sync_lag --sync_nologging
Synchronising standby database see trace file /usr/dbvisit/standby/trace/3566_dbvisit_setup_sync_rawdb_201501132115.trc
-------------------------------------------------------------------------------
Use RMAN incremental backups to synchronise a physical standby database
with the primary database. RMAN incremental backup of the primary
database will be created, starting at the current SCN of the standby,
which in turn will then be used to roll the standby database forward in
time.
RMAN incremental backups can be useful in case the physical standby
database:
     Is lagging far behind the primary database.
     Has widespread nologging changes.
     Has nologging changes on a subset of datafiles.
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------------
PRIMARY
Current SCN:                       2480810             Time: 2015-01-12:23:44:38
Current sequence(s):
  Thread  1     Sequence 107
Last archived sequence(s):
  Thread  1     Sequence 106
STANDBY
Current SCN:                       1127304             Time: 2014-12-08:18:29:10
Next SCN required for recovery:    1127305             Time: 2014-12-08:18:29:10
Sequence(s) required for recovery:
  Thread  1     Sequence 65
No nonlogged transactions detected in standby datafiles.

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Synchronising Standby Database
-------------------------------------------------------------------------------
Step 1 - Deleting previous incremental backup... - done.
Step 2 - Creating incremental backup of primary database... - done.
Step 3 - Creating standby control file... - done.
Step 4 - Transferring backup to standby server... - done.
Step 5 - Restoring standby control file... - done.
Step 6 - Cataloguing incremental backup in RMAN catalogue... - done.
Step 7 - Applying incremental backup to the standby database... - done.
Step 8 - Performing log switch on primary... - done.
Step 9 - Obtaining sync summary... - done.
Step 10 - Updating Dbvisit repository... - done.
-------------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------------
PRIMARY
Current SCN:                       2480988             Time: 2015-01-13:21:19:50
Current sequence(s):
  Thread  1     Sequence 108
Last archived sequence(s):
  Thread  1     Sequence 107
STANDBY
Current SCN:                       2480901             Time: 2015-01-13:21:16:43
Next SCN required for recovery:    2480862             Time: 2015-01-13:21:15:59
Sequence(s) required for recovery:
  Thread  1     Sequence 107
No nonlogged transactions detected in standby datafiles.

-------------------------------------------------------------------------------
To complete standby database sync run dbvisit on the primary, then on the standby server.
=============================================================
dbvisit_setup completed in BATCH mode at 20150113 21:20
=============================================================

 

Following a Syncrhonize Standby database operation,  you must first run Dbvisit Standby as normal to send/apply logs before you can attempt a Graceful Switchover or Activation.

 

Sending Logs (Run on primary first):

oracle@dbvlin502[/usr/dbvisit/standby]: ./dbvisit rawdb
=============================================================
Dbvisit Standby Database Technology (7.0.34.13391) (pid 6839)
dbvisit started on dbvlin502: Tue Jan 13 21:25:11 2015 ()
=============================================================
>>> Obtaining information from standby database (RUN_INSPECT=Y)...
>>> Sending heartbeat message... - done.
>>> Checking Dbvisit Standby for configurational differences between dbvlin502 and
    dbvlin501...
    No configurational differences found between dbvlin502 and dbvlin501.
>>> Log file(s) for rawdb will be transferred from dbvlin502 to dbvlin501...
  > Transferring 'o1_mf_1_107_bccnl6kh_.arc.gz' to server dbvlin501:7890
    Progress: 0%...20%...40%...60%...80%...100% [13816 KB/s] - done.
    1 archive log transfer to dbvlin501 for rawdb completed.
    Last sequence was 107.
    No Mail sent as SEND_MAIL_FLAG = N
>>> Dbvisit Archive Management Module (AMM)
    Config: number of archives to keep      = 0
    Config: number of days to keep archives = 7
    Config: archive backup count            = 0
    Config: diskspace full threshold        = 80%
    Current disk percent full (/u01/app/oracle/flash_recovery_area) = 57%
    Number of archive logs deleted = 2
=============================================================
dbvisit ended on dbvlin502: Tue Jan 13 21:25:41 2015
=============================================================

 

 

Applying Logs (executed on the standby database):

 

oracle@dbvlin501[/usr/dbvisit/standby]: ./dbvisit rawdb
=============================================================
Dbvisit Standby Database Technology (7.0.34.13371) (pid 8959)
dbvisit started on dbvlin501: Tue Jan 13 21:25:43 2015 ()
=============================================================
>>> Log file(s) for rawdb from dbvlin502 will be applied to dbvlin501
201501132125 - Log seq 107 thread 1 applied to standby database rawdb.
    No Mail sent as SEND_MAIL_FLAG_DR = N
>>> Dbvisit Archive Management Module (AMM)
    Config: number of archives to keep      = 0
    Config: number of days to keep archives = 7
    Config: diskspace full threshold        = 80%
Processing /u01/app/oracle/archive/rawdb...
    Archive log dir: /u01/app/oracle/archive/rawdb
    Total number of archive files   : 4
    Exceeded minimum files to leave(3). Files will not be deleted. To increase minimum set
    MIN_ARCH_TO_KEEP variable in Dbvisit Database configuration (DDC) file dbv_rawdb.env on
    dbvlin502
    Number of archive logs deleted = 1
    Current Disk percent full       : 64%
=============================================================
dbvisit ended on dbvlin501: Tue Jan 13 21:26:09 2015
=============================================================

 

Running the log gap report now to ensure the primary and standby databases are in sync:

oracle@dbvlin502[/usr/dbvisit/standby]: ./dbvisit -i rawdb
=============================================================
Dbvisit Standby Database Technology (7.0.34.13391) (pid 7727)
dbvisit started on dbvlin502: Tue Jan 13 21:27:05 2015 ()
=============================================================
Dbvisit Standby log gap report for rawdb at 201501132127:
-------------------------------------------------------------
Standby database on dbvlin501 is at sequence: 107.
Primary database on dbvlin502 is at log sequence: 108.
Primary database on dbvlin502 is at archived log sequence: 107.
Dbvisit Standby last transfer log sequence: 107.
Dbvisit Standby last transfer at: 201501132125.
Archive log gap for rawdb:  0.
Transfer log gap for rawdb: 0.
Standby database time lag (HH:MI:SS): 00:08:06.
    No Mail sent as SEND_MAIL_FLAG = N
=============================================================
dbvisit ended on dbvlin502: Tue Jan 13 21:27:56 2015
=============================================================

 

Example - Batch process in an Oracle RAC environment

Below is an example running the "Synchronize Standby Database" process as a batch process on a 3 Node RAC environment with a single instance standby.

The Synchronize Standby Database process must only be executed on one of the nodes in the primary RAC database.  In this case it was executed on node 1 running instance DEV1.

The Dbvisit Standby DDC file name is "DEV1"

 

oracle@dbvrlin51[/usr/dbvisit/standby]: ./dbvisit_setup --sync --ddc DEV1 --tmp_dir /usr/tmp/ --tmp_dir_dest /usr/tmp/ --sync_lag --sync_nologging
=============================================================
dbvisit_setup started in BATCH mode at 20150114 14:38
csd            =
ddc            = DEV1
restart        =
template       =
output_dir     =
web            =
ddr            =
INTERFACE_MODE = BATCH
=============================================================
./dbvisit_setup --sync --ddc DEV1 --tmp_dir /usr/tmp/ --tmp_dir_dest /usr/tmp/ --sync_lag --sync_nologging
Synchronising standby database see trace file /usr/dbvisit/standby/trace/26574_dbvisit_setup_sync_DEV1_201501141438.trc
-------------------------------------------------------------------------------
Use RMAN incremental backups to synchronise a physical standby database
with the primary database. RMAN incremental backup of the primary
database will be created, starting at the current SCN of the standby,
which in turn will then be used to roll the standby database forward in
time.
RMAN incremental backups can be useful in case the physical standby
database:
     Is lagging far behind the primary database.
     Has widespread nologging changes.
     Has nologging changes on a subset of datafiles.
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------------
PRIMARY
Current SCN:                       59786412            Time: 2015-01-14:14:38:09
Current sequence(s):
  Thread  1     Sequence 2307
  Thread  2     Sequence 2255
  Thread  3     Sequence 2175
Last archived sequence(s):
  Thread  1     Sequence 2306
  Thread  2     Sequence 2254
  Thread  3     Sequence 2174
STANDBY
Current SCN:                       57913893            Time: 2014-12-07:13:04:35
Next SCN required for recovery:    57913894            Time: 2014-12-07:13:04:35
Sequence(s) required for recovery:
  Thread  1     Sequence 2292
  Thread  2     Sequence 2238
  Thread  3     Sequence 2162
No nonlogged transactions detected in standby datafiles.

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Synchronising Standby Database
-------------------------------------------------------------------------------
Step 1 - Deleting previous incremental backup... - done.
Step 2 - Creating incremental backup of primary database... - done.
Step 3 - Creating standby control file... - done.
Step 4 - Transferring backup to standby server... - done.
Step 5 - Restoring standby control file... - done.
Step 6 - Cataloguing incremental backup in RMAN catalogue... - done.
Step 7 - Applying incremental backup to the standby database... - done.
Step 8 - Performing log switch on primary... - done.
Step 9 - Obtaining sync summary... - done.
Step 10 - Updating Dbvisit repository... - done.
-------------------------------------------------------------------------------
SUMMARY
-------------------------------------------------------------------------------
PRIMARY
Current SCN:                       59787417            Time: 2015-01-14:14:47:43
Current sequence(s):
  Thread  1     Sequence 2308
  Thread  2     Sequence 2256
  Thread  3     Sequence 2176
Last archived sequence(s):
  Thread  1     Sequence 2307
  Thread  2     Sequence 2255
  Thread  3     Sequence 2175
STANDBY
Current SCN:                       59786964            Time: 2015-01-14:14:43:58
Next SCN required for recovery:    59786696            Time: 2015-01-14:14:40:46
Sequence(s) required for recovery:
  Thread  1     Sequence 2307
  Thread  2     Sequence 2255
  Thread  3     Sequence 2175
No nonlogged transactions detected in standby datafiles.

-------------------------------------------------------------------------------
To complete standby database sync run dbvisit on all primary nodes, then on the standby.
If a primary node was down during sync operation, you need to run dbvisit with -R option on this node.
=============================================================
dbvisit_setup completed in BATCH mode at 20150114 14:48
=============================================================

IMPORTANT STEP

One important step is now left, run Dbvisit Standby as normal on the primary to send logs to the standby, followed by running Dbvisit Standby on the standby to apply logs

 

 

Â