Testing for Availability - Expert Oracle RAC Performance Diagnostics and Tuning - page 80

Once failover is complete, the query should be executed to verify the current state of both databases. Using the
same query as previously, the new values are

New primary database - 'SSKYDG'
INST INSTN FFS FFCT FFT FFOP OM DUN DBR
---- ------ ------------- ------- --- ------ ---------- ------ --------
1 SSKYDG SYNCHRONIZED SSKYDB 60 YES READ WRITE SSKYDG PRIMARY
The new standby database 'SSKYDB' and instances 'SSKY1' and 'SSKY2';
INST INSTN FFS FFCT FFT FFOP OM DUN DBR
---- ------ ------------- ------- --- ------ -------- ------ ----------
1 SSKY1 SYNCHRONIZED SSKYDB 60 YES MOUNTED SSKYDB PHYSICAL STANDBY
2 SSKY2 SYNCHRONIZED SSKYDB 60 YES MOUNTED SSKYDB PHYSICAL STANDBY

This completes the SWITCHOVER operation; a similar operation is performed to change the databases back to their
original states. Although the entire switchover activity is transparent, Oracle, behind the scene, will make the required
parameter modifications to change the states of the respective databases before requesting a STARTUP operation.

Step 2—Failover
Unplanned failover occurs when the primary database environment is having problems due to either natural disasters
or human errors and a temporary environment is required so the application can have access to the data and business
can continue.
This specific issue has been resolved with Fast-Start Failover Observer (FSFO). When all instances in a RAC
configuration (primary database) fail, the Observer will automatically perform required operations to make the
standby database useable. The failover steps are as follows:

1. The data guard is in a steady state transmitting redo log from the primary to the standby

locations.

2. The Observer is in a monitoring state of the configuration. During this period, the observer

keeps track of both the standby and the primary databases.

3. We assume there was an act of nature causing the primary database, including all

instances in the cluster, to crash.

4. The Observer detects that the primary database is not responding. The Observer

repeatedly tries to make a connection; and after the number of seconds defined by the
FastStartFailoverThreshold, the DGB property declares that the primary environment
is not available.

5. The Observer at this point needs to verify with the standby database if it is ready to fail

over and begins the failover process. The Observer initiates conversion of the standby
database/instance from a “Standby” state to a “Primary” state. Whereas the Observer
initiates this process, it is the remote file server ( RFS) background process on the standby
instance that performs the conversion. During this conversion process, depending on how
active the primary database has been, it may take several minutes for the migration to
complete.

The standby database is taken into a NOMOUNT state after performing a dismount of the
already mounted instance.

a.

b. A new control file is created with the required default parameters.

c. Database recovery is performed.