Failover is a emergency practice to avoid any point of failure,business impact due to loss of service and acts as a high availability.There is data loss from the point of failure
The issue occurs due to unexpected event like disaster,war,datacenter destruction etc
So we have two objectives : RTO(recovery time objective) and RPO(recovery point objecive)
RTO: how much application downtime can be compromised by business??
RPO: how much data loss can be compromised by business??
Based on individuals business objective,one can choose the redundancy and resiliency levels
We are going to simulate a failover event ourself in this article
Terms used:
Primary database : orcl –> failed old primary database –>New standby database
Standby database : orcldg –> old standby database –> New primary database
On primary:
Consider a critical financial application is connected to the database and loss of service would lead to loss of revenue
You have to somehow face the challenge when you get a surprise failure on the mission critical database and save the downtime but can tolerate some dataloss
simulate a failure on primary by aborting the instance.
Assume a hurricane damage on the primary datacenter XYZ location
On standby:
Standby database is located on ABC which is different region
Check the status of the standby database
Cancel the MRP and issue the command to failover services to standby as below
Alter database failover to "standby_database_name";
Then open the database for read write operations
Now old standby database became new primary
The log sequence number will be reset after a failover due to unexpected failure on the primary database and inconsistent recovery
Reinstate failed old primary database to new standby:
After the failover,the standby database acts as a primary and primary database acts as a standby after reinstation which is called role transition
Once the new primary(old standby) is up for application connectivity,we can reinstate the old primary database if flashback is enabled on failed primary database
If flashback is not enabled,then we need to rebuild the failed whole primary database from the beginning
Hence it is always recommended to enable flashback on primary database to be on safer side
On failed old primary database:
Get the last scn when primary database failed during disaster and mark the scn number
flashback the database using the marked scn from the previous step and convert the old failed primary to new physical standby database
Finally enable MRP and switch some logfiles on the new primary database(orcldg) to test the synchronization of scn
Note: If the dataguard protection is in max protection or availability mode before failure,then after failover event happen the protection mode become max performance !!
