Test Standby Activation is a guided process which is designed to help you process DR Tests without additional effort.
| Table of Contents | ||
|---|---|---|
|
1. Considerations
In general, any DR test is done best by the Activation (Failover) method, because this is the exact method which will be used in real life disaster scenario. It is possible to perform DR test with Graceful Switchover Process (GS). While GS allows to test the DR site functionality, the GS process is very different from Activation. The disadvantage of the failover is that activation can’t be rolled back and in order to re-establish the synchronization, activated database has to deleted and user must recreate standby database from the scratch.
Test Standby Activation helps to automate this whole process. It consists of three main steps:
A. backup of standby database on standby server
B. activation of standby database
C. restore of the backup which was done earlier to reinstate the standby database
| Note |
|---|
There are two very important conditions to run this process:
|
| Info |
|---|
Test Standby Activation is a complex process and as such it doesn’t include any automatic rollback mechanisms. If you will encounter any error during the whole process- for example restore of the standbvy database will fail, you will need to fix the resulting situation manually. This is done usually by deleting the DDC from fomr dbvcontrol GUI, importing it back again and recreating standby database from the scratch. |
2. Starting Test Standby Activation (Backup)
In this initial part, the backup of your standby database will be created on standby server.
First step in this process is to disable the Automatic Standby Update (ASU). Refer to Post Tasks - Automatic Standby Update (ASU) for details.
| Info |
|---|
DR Test Activation will automatically disable and enable the ASU when executed from GUI, but we recommend to manually operate the ASU. |
| Note |
|---|
Ensure the archivelogs are not deleted from production during the DR testing operation. Once the test is completed the archivelogs required by standby has to be sent from primary. This should be from the point where backup of the database was taken prior to activation. |
Once ASU is disabled, proceed with starting the process from GUI ACTIONS pane by selecting “Test Standby Activation”:
...
When starting the backup you can select various options:
...
Number | GUI Field Name | Values and explanation |
1 | Backup Type | There are two possible choices: Image Copy and Backupset Backupset: common RMAN backupset by default compressed, You may specify DDC parameter RMAN_DBF_BACKUP_TYPE = AS BACKUPSET. Value “AS COPY” will not have any effect. DDC File Reference Image Copy: Backup as image copy which will later enable you to switch to copy or restore from the image copy. Check the part “4. Standby Database Backup Restore (Reinstate)” for more information on how the restore from image copy works. |
2 | Backup Format | Backup file name format as defined on Oracle Database documentation. |
3 | Backup Location | Directory on standby server where the whole backup will be done. Provided backup location must not be under any databaselocation (FRA, Datafile directory etc ..) and also avoid using ARCHDEST. The size needed is the same as the backup which was generated during CSD process. |
5 | Stop Before Activation | There are two possible choices: Yes and No Yes: After the backup is finished, Dbvisit will leave the original standby database intact and you will have to manually initiate the activation. This is useful for being in more control. But can cause delays, because the backup is often few hours long and user has to manually activate. No: After the backup is finished, Dbvisit will automatically activate the standby database without any need for prompt or manual action. This is useful to make the whole process more streamlined. |
9 | Start | Starts the backup process |
One the backup is started, you will see a new task in the task bar:
...
And you will be able to view its details:
...
Once the backup task is finished, depending on your choice, you can proceed with the activation, or you can skip to reinstate part.
| Info | ||
|---|---|---|
Because the ASU is stopped for the whole duration of the DR Test, the archivelogs generated during DR Test by primary database will not be transferred. You can however manually initiate the transfer by running “dbvctl -d <DDC>” command on primary, for example:
This helps with managing the archivelog backlog on the primary. You can encounter error “Error Code=2151 Destination database not available” during the processing, but you can ignore it. You can also consider scheduling this command in the crontab / widows scheduler for the duration of the DR test. You must however ensure to disable this schedule before enabling the ASU again. |
If you chose that you don’t want to stop before activation, the task will include the activation as well:
...
3. Standby Activation (Failover)
This step is done automatically if you chose “No” for “Stop Before Activation” choice when doing the backup. To activate the standby database, choose “Resume Standby Activation Test” from the ACTIONS pane:
...
You will see a backup summary:
...
Once you click on Start the Activation will commence and you will see a new task:
...
You can check the details:
...
The Activation is usually done within few minutes. The internal Activation process done during this procedure, is entirely the same as the Activation (Failover) process which is executed during real life Disaster Situations:Standby Database Activation (Failover)
Your standby database will gain “Activated for DR Test” status:
...
This Status will prevent most of the commonly available actions from being executed on standby database. Once you are finished with your DR Testing (for example connecting test application to verify DR site functionality) you can proceed to restoring the backup (Reinstate) step.
4. Standby Database Backup Restore (Reinstate)
To restore the backup and standby database to its state from before the activation, choose the “Reinstate Standby Database” Option from the ACTIONS pane:
...
You will be able to see the backup summary if you chose to backup as BACKUPSET:
...
and following summary if you chose to backup as IMAGE COPY:
...
If you used image copy as form of backup, you will be given an option “Do you want to switch the standby database to the image copy”:
Yes: instead of restoring the original standby database from the image backup (copy files), the standby database will be immediately switched to the backup image copy. This is almost immediate action very much reducing the time needed to restore, but the resulting standby database will have datafiles located in the backup location. For example in this case /tmp/dr_test/DBV_SLASH_1195376_kg3ilpv7.dbf etc … This is not always desirable.
No: the standby database will not be switched to image copy, instead the image copy will be used for restoring the original datafile. This is in general faster than restoring the backupset.
Regarless the backup type you have, once you click on start, Dbvisit will:
shut down the activated standby database
delete all files generated by new incarnation of the standby database (after it was activated)
restore the backup (either from backupset or image copy) or switch to image copy.
Once the reinstate process starts, you will be able to see a new task
...
And also check its details:
...
The last step is to enable ASU again, see: Post Tasks - Automatic Standby Update (ASU)
| Info |
|---|
Before enabling ASU again, make sure that you disable any manual dbvctl schedules (if you did enable it) otherwise dbvctl schedules will conflict with ASU. |