Oracle Data Guard role conversion

Oracle Data Guard role conversion experiment environment: OEL + Oracle11.2.0.3 + physical standby as we all know, Data Guard is already the mainstream disaster tolerance solution of today's standards. Due to the strong adaptability of log transmission to the network, in addition, synchronous real-time transmission and asynchronous delay transmission can be used, or even Remote Disaster Recovery solutions. Regardless of the purpose, the DG will inevitably require role conversion, namely switching the standby database to the primary database. role conversion can be divided into switchover and failover; the two differences are compared from three perspectives: (1) different application scenarios: Switchover is used for Switchover in preparation and planning, usually for normal tasks such as system upgrade and data migration; failover is used for unexpected emergencies, such as power loss and natural disasters.
(2) different degrees of data loss: Switchover will not lose data, and Failover usually means that some data is lost. (3) different solutions: After Switchover, the crash uard environment will not be damaged, and any system with the Primary and Standby roles will exist. However, after Failover, the deployment uard environment will be damaged and must be rebuilt. 1. Switchover because the conversion of Switchover is manually triggered by the DBA, the steps of Switchover are standardized. The Switchover process begins with the Primary Database and ends with the Standby Database. The steps for Switchover are as follows: 1. Check the database Switchover status on the master database. SQL> select switchover_status from v $ database; SWITCHOVER_STATUS: TO STANDBY indicates normal Switchover. if the value of SWITCHOVER_STATUS is sessions active, the current session is ACTIVE. 2. The master database is switched normally. If the value of SWITCHOVER_STATUS is to standby: SQL> alter database commit to switchover to physical standby; database altered. if the value of SWITCHOVER_STATUS is sessions active: SQL> alter database commit to switchover to physical standby with se Ssion shutdown; Database altered. after the Primary Database receives this command, these events occur: (1) After the command is executed, Redo is not generated on the master Database, and all DML-related Cursor will fail, the user will no longer be able to execute transactions. (2) The current log of each log Thread is archived, and a special switch standard EOR (End of Redo) is recorded in the new log header of each Thread next, and then archived again, the result is that the EOR is sent to all Standby databases, and the Primary Database is converted to Standby. (3) On this old Primary Database, the MRP (Managed Recovery Process) Process will automatically start and apply the last archived log, that is, the EOR log, once this EOR application is complete, the Database will be Dismounted and must be started into a Standby Database. 3. Restart the previous master database SQL> shutdown immediate; (11g sometimes requires shutdown abort, or an error is reported) SQL> startup mount; 4 at this time TO the backup database in the slave database TO verify the switchover status SQL> select switchover_status from v $ database; SWITCHOVER_STATUS-----------------TO_PRIMARY1 row selected5 TO the target slave database TO the master database if the value of SWITCHOVER_STATUS is TO STANDBY: SQL> alter database commit to switchover to primary; Database altered. if the value of SWITCHOVER_STATUS is sessions active, then: SQL> alter database commit to switchov Er to primary with session shutdown; Database altered. after executing this command, the control file of the Standby Database is also converted from the Standby control file to the standard control file. Then, the database can open the Database and open it into a business database. 6. Restart the target slave database SQL> shutdown immediate; SQL> startup; 7. run SQL> alter database recover managed standby database disconnect in the previous master database; 8. Check the role status of the master and slave databases: select switchover_status, database_role from v $ database; so far, a complete Switchover completes the role swap and can be used normally. 2. Once a Crash (for example, an abnormal power loss or hardware failure) occurs in the primary database, Failover cannot be resumed for a short period of time. In this case, to restore the service to normal as soon as possible, you usually need to perform the failover operation, force open the Standby database. Failover usually means a certain amount of data is lost, and the data loss problem is particularly prominent when Primary Database is RAC. Failover steps are as follows: 1. Stop the Application Log: SQL> recover managed standby database cancel; Media recovery complete.2 force stop the log application and execute the following command: SQL> alter database recover managed standby database finish [force]; Database altered. this force is optional. This Command tells the MRP of Standby Database. Do not wait for Redo again, and apply as many existing Redo records as possible, and simulate a Switchover command. The force parameter is used to close the PFS process. Otherwise, when the MRP process sees that the RFS process still exists, it will think that the corresponding Primary Database is still normal, and the process failover and 11G will not be allowed, the force parameter is the default parameter, and the force parameter is also canceled. Once the finish command is complete, the Data Protection Mode of DG will be downgraded to Maximun Performance, regardless of the original protection level. 3. Run switchover: SQL> alter database commit to switchover to primary with session shutdown; Database altered.4 open database. SQL> alter database open; when the Database is opened, the new Primary Database will try to connect to the Standby Database (that is, the faulty Primary database ), therefore, the opening process will be suspended for a period of time. After several attempts, the database will eventually be opened. At this time, the database protection level is Maximun Performance, and it needs to be upgraded to another level manually in the future.