Oracle] Data Guard Analysis of Switchover and Failover

The following is a detailed analysis of the use of Switchover and Failover in Oracle. For more information, see

Role Switching between Data Guard master and slave databases is divided into the following two types:
1) Switchover
Swithchover is generally designed to switch roles, such as upgrading. It is usually lossless, that is, there will be no data loss.Its execution is divided into two phases:
1. convert Primary to Standby
2. Convert Standby (one) to Primary
2) Failover
Failover means that because a Primary fault cannot be recovered in a short time, Standby has to act as a Primay. If it is in the highest-performance mode, this switchover may lead to data loss.

The following describes the Switchover and Failover of physical Standby (logical Standby switching is similar ).

1. Perform Switchover for physical Standby
1) Check whether pirmary can be switched to standby
PRIMARY> select switchover_status from v $ database;
SWITCHOVER_STATUS
--------------------
TO STANDBY
2) Switch primary to standby.
PRIMARY> alter database commit to switchover to physical standby;
3) Start the original primary to the mount status.
In this case, the original primary is running as standby.
4) Check whether standby can be switched to primary
STANDBY> select switchover_status from v $ database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
5) Switch standby to primary.
STANDBY> alter database commit to switchover to primary;
Database altered.
STANDBY> alter database open;
Database altered.
6) Verification
PRIMARY> select database_role from v $ database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
STANDBY> select database_role from v $ database;
DATABASE_ROLE
----------------
PRIMARY
We can see that the original primary is now standby, and the original standby is changed to primary.
Check whether the log_archive_dest parameter of the new primary is set correctly:
STANDBY> show parameter log_archive_dest_2
NAME TYPE VALUE
-----------------------------------------------------------------------------
Log_archive_dest_2 string service = O01DMS0 ARCH VALID_FOR
= (ONLINE_LOGFILES, PRIMARY_ROLE
) DB_UNIQUE_NAME = O01DMS0
STANDBY> show parameter log_archive_dest_state_2
NAME TYPE VALUE
--------------------------------------------------------------------
Log_archive_dest_state_2 string ENABLE
Log switch on the new primary end:
STANDBY> alter system switch logfile;
System altered.
STANDBY> select max (sequence #) from v $ archived_log;
MAX (SEQUENCE #)
--------------
479
View on the new standby end:
PRIMARY> select max (sequence #) from v $ archived_log;
MAX (SEQUENCE #)
--------------
479
The maximum number of archived logs on both sides is consistent, indicating that switchover is successful.

2. Run Failover on physical Standby.
1) check whether the standby archive files are continuous
STANDBY> select thread #, LOW_SEQUENCE #, HIGH_SEQUENCE # from v $ ARCHIVE_GAP;
No rows selected
This step is important. Make sure that all generated archive files have been uploaded to the standby server.
If the preceding statement returns results, you must copy the missing archive file from the primary end to the standby end, and then add it to the database using the following command:
STANDBY> alter database register physical logfile 'filespec'
2) check whether the standby archive file is complete
STANDBY> select unique thread # as thread, MAX (SEQUENCE #) OVER (partition by threa
D #) as last from V $ ARCHIVED_LOG;
THREAD LAST
--------------------
1 479
Using the preceding statement, we can find that the maximum archive log of standby is 479. If there are more archive logs than 479 on the primary end, copy them, then, run the following command to add it to the database:
STANDBY> alter database register physical logfile 'filespec'
3) Start failover
Alter database recover managed standby database finish force; 4) switch TO primaryTER database commit to switchover to primary;
Alter database open; STANDBY> select database_role from v $ database; DATABASE_ROLE----------------PRIMARY