Synchronize a Standby Database using Batch Mode
The process to synchronize the standby database can be run in 3 ways:
- Using the Command Line Interface (CLI) using the setup menu
- Using the Web Based User Interface (GUI)
- 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:
| Option | Description |
|---|---|
| --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_lag | This parameter is specified to tell the dbvisit setup sync process to syncronize the standby database with the primary database - required parameter |
| --sync_nologging | This 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