Oracle 11g DG Broker automatic failover
Oracle 11g DG Broker automatic failover verification:
db2 main library:
SQL> select DATABASE_ROLE,OPEN_MODE from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PRIMARY READ WRITE
db1 is standby
SQL> select DATABASE_ROLE,OPEN_MODE from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY WITH APPLY
The db2 main library simulation is closed abnormally
SQL> shu abort
ORACLE instance shut down.
Check the status of db1 again:
SQL> select DATABASE_ROLE,OPEN_MODE from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PRIMARY READ WRITE
Four: The process of automatic switching:
4.1: The test takes about 10 seconds to detect the failure of the main library by the observer!
DGMGRL> start observer;
Observer started
20:15:59.44 Thursday, July 04, 2019
Initiating Fast-Start Failover to database "db2"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "db2"
20:16:01.77 Thursday, July 04, 2019
4.2 The process of failover is the same as manual failover.Whether it is automatic failover or manual execution of FAILOVER TO, the following two commands are executed with the command line failover command:
alter database recover managed standby database finish force;---stop rfs process
alter database commit to switchover to primary;---由open到mount
alter database open; ---- open with read write
When a failover occurs, you can see that it is indeed such a process through the following
1).Start state: rfs and mrp processes are normal
SQL> select process,status ,sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 14
RFS IDLE 0
RFS IDLE 15
RFS IDLE 0
MRP0 APPLYING_LOG 15
8 rows selected.
2) The.rsf process disappeared
SQL> select process,status ,sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 14
MRP0 APPLYING_LOG 15
3).The database becomes mounted
SQL> select DATABASE_ROLE,OPEN_MODE from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY MOUNTED
4) The database becomes open write
SQL> select DATABASE_ROLE,OPEN_MODE from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PRIMARY READ WRITE
4.3: Execute failover manually;
DGMGRL> help failover
Changes a standby database to be the primary database
Syntax:
FAILOVER TO <standby database name> [IMMEDIATE];
When a failover occurs:
Check the status of the configuration: It is found that the original main library needs to be reinstated, and it needs to be repaired with the REINSTATE command to become a slave library of the new main library!
DGMGRL> show configuration
Configuration - dbha_c
Protection Mode: MaxPerformance
Databases:
db2 - Primary database
Warning: ORA-16829: fast-start failover configuration is lagging
db1 - (*) Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: ENABLED
Configuration Status:
WARNING
First start the original main library to mount state:
SQL> startup mount
DGMGRL> help reinstate
Changes a database marked for reinstatement into a viable standby
Syntax:
REINSTATE DATABASE <database name>;
DGMGRL> REINSTATE DATABASE db1
Reinstating database "db1", please wait...
Reinstatement of database "db1" succeeded
Check the original main library again:
SQL> select process,status ,sequence# from v$managed_standby;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CONNECTED 0
ARCH CLOSING 5
RFS IDLE 0
RFS IDLE 0
RFS IDLE 0
RFS IDLE 6
MRP0 APPLYING_LOG 6
In fact, reinstate executes the following process:
If you want to convert the original main library to the new standby library
The original main library must have the function of flashbackup database enabled.After failover,
1.Check the scn number when the failover from the library became the master.
SQL> select STANDBY_BECAME_PRIMARY_SCN from v$database;
STANDBY_BECAME_PRIMARY_SCN
--------------------------
15468
2.Flash back the original main library to the scn number of 15468;
SQL>FLASHBACK DATABASE TO SCN 15468 ;
Database altered.
3.Perform the switch in the original main library:
SQL> alter database convert to physical standby ;
Database altered.
4.Close the original main library
SQL>shu immediate
5.Open the original main library to mount state,
SQL>startup mount;
6.Archive the newly generated logs on the new main library to the new standby library
SQL>alter system archive log current;
7.Open the mrp process application log to replay the changes
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
5.View status:
SQL> select process,status from v$managed_standby;
PROCESS STATUS
--------- ------------
ARCH CLOSING
ARCH CONNECTED
ARCH CONNECTED
ARCH CLOSING
MRP0 APPLYING_LOG
RFS IDLE
RFS IDLE
RFS IDLE
So far, the original main library has become the standby of the new main library.
0 Comments