[Oracle] Data Guard series (6)-role conversion

[Oracle] Data Guard series (6)-role conversion
The core function of DG is to provide high-availability Disaster Tolerance. Therefore, the role conversion content described in this section is the most important part of DG. Role Switching between master and slave databases of DG is divided into the following two types: 1) SwitchoverSwithchover refers to role switching between master and slave databases (master database is changed to slave database, slave database is changed to master database ), it is usually artificial and planned. For example, Switchover can reduce the downtime of database upgrades, so data will not be lost. 2) FailoverFailover means that the master database cannot be restored within a short period of time due to a fault. To ensure data availability, the slave database has to temporarily act as the master database. If the data protection mode of DG is the maximum performance mode, this type of switch may cause data loss. The following shows the Switchover and Failover of the physical standby database and the logical standby database respectively. switchover of the physical STANDBY database 1) check whether the master database can be switched TO the STANDBY database [SQL] SQL> select switchover_status from v $ database; SWITCHOVER_STATUS ---------------- TO STANDBY 2) switch the master database to the physical standby database [SQL] SQL> alter database commit to switchover to physical standby; 3) shut down the master database and restart it to the mount status [SQL] SQL> shutdown abort SQL> startup mount. At this time, the identity of the master database has changed and become a physical standby database. 4) check whether the physical standby database can be switched TO the master database [SQL] SQL> select switchover_status from v $ database; SWITCHOVER_STATUS ------------------ TO PRIMARY 5) switch the original physical standby database to the new master Database [SQL] SQL> alter database commit to switchover to primary; Database altered. SQL> alter database open; Database altered. 6) Start the log application in the new master DATABASE [SQL] SQL> alter database recover managed standby database using current logfile disconnect from session; 7) Verify [SQL] SQL> select databa Se_role from v $ database; DATABASE_ROLE -------------- physical standby SQL> select database_role from v $ database; DATABASE_ROLE -------------- PRIMARY can be seen from above that the original master database has now become PHYSICAL, the original physical standby database becomes the master database. Check whether the parameters of the new master database are correctly set: [SQL] SQL> show parameter NAME TYPE VALUE ----------- export log_archive_dest_2 string service = O01DMS0 ARCH VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = O01DMS0 SQL> show parameter log_archive_dest_state_2 NAME TYPE VALUE -------------------------------------------------- ------------------ Log_archive_dest_state_2 string ENABLE switches logs in the new master database to check whether logs can be successfully transferred to the new slave database: [SQL] SQL> alter system switch logfile; System altered. SQL> select max (sequence #) from v $ archived_log; MAX (SEQUENCE #) ------------ 479 view in the new slave Database: [SQL] SQL> 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 ~ Failover of the physical standby database 1) Refresh unsent logs from the primary database to the standby database. If the primary database can be mounted, we may refresh the unsent logs to the standby database, this will not cause data loss. After the master database is mounted, run the following statement: SQL> ALTER SYSTEM FLUSH REDO TO standby_db_unique_name. If the preceding statement is successfully executed, all logs have been sent TO the slave database. You can skip TO step 1, otherwise, start from step 1. 2) check that the slave database has the latest archive log to query the maximum number of archive logs of the slave database: [SQL] SQL> SELECT UNIQUE THREAD # AS THREAD, MAX (SEQUENCE #) OVER (partition by thread #) as last from V $ ARCHIVED_LOG; thread last ---------- 1 100 manually copy the missing archive log to the slave database and register it in the slave database: [SQL] SQL> alter database register physical logfile 'filespec1'; 3) solve the archive log GAP query v $ archive_gap view and check whether the GAP [SQL] SQL> SELECT THREAD #, LOW_SEQUENCE #, HIGH_SEQUENCE # from v $ ARCHIVE_GAP; THREAD # LOW _ SEQUENCE # HIGH_SEQUENCE # ---------- ---------------------- 1 90 92 indicates that the standby database is missing 90, 91, 92 archiving logs. manually copy them from the primary database and register them in the standby database: [SQL] SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'; 4) Repeat steps 2nd and 3 until no GAP exists. Otherwise, data will be lost. 5) slave DATABASE stop log application [SQL] SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 6) apply all logs that have not been applied and execute the following statement to apply all logs: [SQL] SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; if the execution of the preceding statement is correct, proceed to the next step. The error is analyzed based on the specific error information. After the error is resolved, re-execute the appeal statement. If the error cannot be resolved, run the following statement to continue Failover, but some data is lost. [SQL] SQL> alter database activate physical standby database; 7) Confirm that the slave DATABASE is ready TO switch TO the master DATABASE [SQL] SQL> SELECT SWITCHOVER_STATUS FROM V $ DATABASE; SWITCHOVER_STATUS --------------- TO PRIMARY 8) switch the physical standby database to the new master DATABASE [SQL] SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN; after the SWITCHOVER is successful, open the new master DATABASE and verify that: [SQL] SQL> alter database open; SQL> select database_role from v $ database; DATABASE_ROLE -------------- PRIMARY