1. Introduction
When disaster strikes and the primary database is no longer available the standby database must be activated to become the new primary database to continue operation. This is also called failover to the standby database.
The steps to activate the standby database are:
- Stop the scheduling of Dbvisit Standby.
- Change the network configuration (or DNS) so that users will connect to the standby database (or server) instead of the primary database (or server).
- Activate and open the standby database for normal operation as per instructions below. Note that as soon as the standby database is activated and becomes the new primary database that is open read/write. The link to the original primary database is lost and it is no longer possible to apply new logs to the original standby database.
To activate and open the standby database for continued operation in the event of a disaster the following procedure discussed in this section must be used.
| Table of Contents |
|---|
2. Activate (Failover) - Using the Command Line Interface
The command line options available to activate the standby database are:
| No Format |
|---|
dbvctl -d <ddc> -o activate [--force] [--nosync] |
This command is used to Activate the standby database, during which process it becomes the new primary database. Important, this operation MUST be done with caution as the process is NOT reversible. This action is performed in the event that the primary database is no longer available. Dbvisit Standby will prompt before activating the standby database. If the --force option is provided then Dbvisit Standby will no longer prompt before activating the standby database (this option can be used in batch mode).
Note: On the event that APPLY_DELAY_LAG_MINUTES (i.e. APPLY_DELAY_LAG_MINUTES = 180) is set in the DDC, and standby is activated in batch mode, it will most likely fail or canceledcancelled. If APPLY_DELAY_LAG_MINUTES is set in the DDC, the correct way of activating the standby is via interactive mode and not using the option --force.
If the --nosync option is provided, Dbvisit Standby will not transfer the updated (reversed) DDC file to the original primary if any schedules are running on the newly activated primary. When the standby database is activated it is no longer possible to keep the new primary and the old primary databases in sync. A new standby database must be created after activation.
Before you activate the standby database, running a quick test by ensuring the standby database is in a consistent state (datafile headers and controlfile is are in sync) and ready to be activated. This can be done by opening the standby database read-only.
This is done by running the following command: "./dbvctl -d DEV -o read"
Example:
| No Format |
|---|
[oracle@dbv2 /usr/dbvisit/standby]$ ./dbvctl -d DEV -o read ============================================================= dbvctl started on dbv2: Sun Nov 13 10:51:23 2016 ============================================================= Open Standby Database DEV in READ ONLY mode... Standby Database DEV opened in READ ONLY mode. Log files cannot be applied to Database while in READ ONLY mode. Database tempfile(s) may need to be added to this database. ============================================================= dbvctl ended on dbv2: Sun Nov 13 10:51:24 2016 ============================================================= |
As we can see in the example above, the standby database can be opened read-only without any errors.
If you did get any errors, example stating file 1 needs more recovery, you will need to apply more archive logs before you will be able to successfully activate (open the standby database read/write).
Now that we know we can open the standby read-only, lets let's start it back into recovery mode (mount state), by running: "./dbvctl -d DEV -o restart"
Example:
| No Format |
|---|
[oracle@dbv2 /usr/dbvisit/standby]$ ./dbvctl -d DEV -o restart ============================================================= Dbvisit Standby Database Technology (8.0.04.18169) (pid 3335) dbvctl started on dbv2: Sun Nov 13 10:52:11 2016 ============================================================= Stopping instance DEV... Standby Instance DEV shutdown successfully on dbv2. Starting instance DEV... Standby Instance DEV started ============================================================= dbvctl ended on dbv2: Sun Nov 13 10:52:19 2016 ============================================================= |
Now that we know the standby database can be opened read-only and that it is in a consistent state that it can be opened, we can execute the "Activation"
The example below shows the process being is executed to activate the standby database for DDC file DEV:
| No Format |
|---|
[oracle@dbv2 /usr/dbvisit/standby]$ ./dbvctl -d DEV -o activate
=============================================================
Dbvisit Standby Database Technology (8.0.04.18169) (pid 3420)
dbvctl started on dbv2: Sun Nov 13 10:52:38 2016
=============================================================
Activating means this database will become a Primary Database.
It will no longer be a Standby Database for DEV on dbv1.
Activation cannot be reversed.
=>Activate Standby Database on dbv2? <Yes/No> [No]: Yes
Are you sure? <Yes/No> [No]: Yes
>>> Activating now...
File /usr/dbvisit/standby/conf/dbv_DEV.env copied to /usr/dbvisit/standby/conf/dbv_DEV.env.201611131052.
>>> Activation complete. Please ensure a backup of this Database is made
>>> Old archives from before the activation should be removed to avoid mix-up between new
and old archive logs
>>> If the Dbvisit Standby process is to be reversed, then database on dbv1 will need to be
rebuilt as a Standby Database
=============================================================
dbvctl ended on dbv2: Sun Nov 13 10:53:35 2016
============================================================= |
Next Steps:
As soon as possible, back up your new production database.
At this point, the former standby database is now your production database.
This task, while not required, is a recommended safety measure because you cannot recover changes made after activation without a backup.
3. Activate (Failover) - Using the Central Console
The Central Console can also be used to Activate a Standby Database.
As recommended above, the first test that you can open the standby database "read-only".
Fore more detail see Using the Central Console - (Dbvserver)Dbvserver#Dbvserver-11.5.DatabaseStatus,Restart,StartandStop
To Activate the standby database, navigate to the "Activate Standby Database" main screen option.
You will be taken to the Activate Standby Database menu from where you can now select the DDC, specify if you want to allow the sync option - which will allow the DDC file and archive logs from this new primary to be copied to the old primary. In most cases, the recommended value to specify here is "NO" to not allow this.
Then Click on submit and the standby database activation process will start.
Next Steps:
As soon as possible, back up your new production database.
At this point, the former standby database is now your production database.
This task, while not required, is a recommended safety measure because you cannot recover changes made after activation without a backup.