...
| 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 standby database will fail, you will need to fix the resulting situation manually. This is done usually by deleting the DDC from from fomr dbvcontrol GUI, importing it back again and recreating standby database from the scratch. |
If your requirement is to perform DR test while primary is down or you can’t maintan the primary server reachability, you will need to perform DR with the help of normal Activation (Failover) process described here:
Activate Standby Database Activation (Failover)
2. Starting Test Standby Activation (Backup)
...
| 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 after the DR test is finished. |
If you chose that you don’t want to stop before activation, the task will include the activation as well:
...
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:Activate Standby Database Activation (Failover)
Your standby database will gain “Activated for DR Test” status:
...