Automatic Failover
Automatic failover is where the software determines when the standby database should be activated to become the new primary database. There are numerous conditions that can occur (ie: network glitches/outages) in any system which theoretically could disrupt communications between the primary and standby sites. Because of this variability the decision to perform a failover, and activate the standby database, is often left in the hands of the operator(s). However, it is possible to automate this failover process, if one chooses to do so, and was aware of the associated risk inherent in this. This could be achieved with some scripts or a basic app, created to run on the standby server or a third "observer" server.
Standby™️ v9.0.02+ has enabled automatic failover to the standby database, performing status checks and initiating automatic failover when an error is detected based on pre-defined rules.
What happens during activation?
What happens when the Oracle standby database is activated to become a primary database? To activate the standby database one of the following commands can be given: 1) Manual SQL comand:
SQL> alter database activate standby database;
SQL> shutdown immediate;
SQL> startup
2) Dbvisit command:
dbv_oraStartStop activate database_name
Ensure that all archives have been applied to the standby database before activating the standby database. Activating the standby database initiates an OPEN RESETLOGS operation on the standby database to create the redo logs. The redo logs are newly created because in its normal standby database state, the redo log files are not present and are not needed. Note Oracle Enterprise Edition uses standby redo logs, but these are different to normal redo logs. When you create a standby database, you actually do not need to copy the redo logs from the primary database. So the OPEN RESETLOGS operation creates the physical redo log files. If Oracle cannot create the redologs then the operation will fail and the database will still be a standby database. Oracle uses the information from the controlfile to determine where to create the redo log files. The redo log file information in the standby controlfile is therefore just a reference to where the redolog files should be created if OPEN RESETLOGS operation is given.
Example
In the example below the redo log is renamed to an invalid filename to emulate what happens when the standby database is activated:
SQL> alter database rename file '/oracle/oradata/dbvisitp/redo01.log'
to '/oracleX/oradata/dbvisitp/redo01.log';
Database altered.
SQL> alter database activate standby database;
alter database activate standby database
*
ERROR at line 1:
ORA-00344: unable to re-create online log
'/oracleX/oradata/dbvisitp/redo01.log'
ORA-27040: file create error, unable to create file
Linux Error: 2: No such file or directory
The database is still a standby database as the activation failed. We cannot manually create the redo logs, as this is an Oracle internal operation. The only thing we can do is to give the correct location for the redo log files. Rename the redo log to the correct location:
SQL> alter database rename file '/oracleX/oradata/dbvisitp/redo01.log' to
'/oracle/oradata/dbvisitp/redo01.log';
Database altered.
SQL> alter database activate standby database;
Database altered.
SQL>
The standby database has been activated and is now a primary database. Oracle has created the redo logs at the location specified. Note: all previous backups of this database are now invalid and cannot be used to restore this database. This is because of the RESETLOGS command which resets the archive sequence number (SEQUENCE#) and invalidates all previous archive logs. The SCN number of the database is not reset. Now is a good time to make a new backup of your database!
Download a free Standby™️ 10 Day Trial today.
Back to Blog
