​Oracle 11g dg broker自动failover

Oracle 11g dg broker自动failover验证：

db2主库：

SQL> select  DATABASE_ROLE,OPEN_MODE from  v$database;

DATABASE_ROLE    OPEN_MODE

---------------- --------------------

PRIMARY          READ WRITE

db1为standby

SQL> select  DATABASE_ROLE,OPEN_MODE from  v$database;

DATABASE_ROLE    OPEN_MODE

---------------- --------------------

PHYSICAL STANDBY READ ONLY WITH APPLY

db2主库模拟异常关闭

SQL> shu abort

ORACLE instance shut down.

再次查看db1的状态：

SQL> select  DATABASE_ROLE,OPEN_MODE from  v$database;

DATABASE_ROLE    OPEN_MODE

---------------- --------------------

PRIMARY          READ WRITE

四：自动切换的过程：

4.1:测试大概需要10秒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 failover的过程和手工failover一样，不管是自动failver，还是手动执行FAILOVER TO ，都是执行了用命令行failover的命令如下两条命令：

alter database  recover managed standby database finish force;---停止rfs进程

alter database commit to switchover to primary;---由open到mount

alter database open;      ----read write 方式打开

发生failover的时候，通过如下可以看到确实是这么个过程

1）.开始状态: rfs和mrp进程都正常

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）.rsf进程消失

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）.数据库变成了mounted

SQL> select  DATABASE_ROLE,OPEN_MODE from  v$database;

DATABASE_ROLE    OPEN_MODE

---------------- --------------------

PHYSICAL STANDBY MOUNTED

4）数据库变成open  write了

SQL> select  DATABASE_ROLE,OPEN_MODE from  v$database;

DATABASE_ROLE    OPEN_MODE

---------------- --------------------

PRIMARY          READ WRITE

4.3：手动执行failover；

DGMGRL> help failover

Changes a standby database to be the primary database

Syntax:

FAILOVER TO <standby database name> [IMMEDIATE];

当发生failover的之后：

查看 configuration的状态：发现原来的主库 needs to be reinstated，需要使用REINSTATE命令修复下，才能变成新的主库的从库！

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

首先启动原来的主库到mount状态：

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

再次查看原来的主库：

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

实际上reinstate就是执行了下面的过程：

如果要转换原来的主库为新的备库

要求原先的主库必须开启了flashbackup database的功能，在failover后，

1.查看从库failover成为主的时候的scn号。

SQL> select  STANDBY_BECAME_PRIMARY_SCN      from  v$database;

STANDBY_BECAME_PRIMARY_SCN

--------------------------

15468

2.闪回原来的主库到15468 的scn号；

SQL>FLASHBACK DATABASE TO SCN 15468 ;

Database altered.

3.在原来主库执行切换：

SQL> alter database convert to physical standby  ;

Database altered.

4.关闭原来的主库

SQL>shu  immediate

5.打开原来的主库到mount状态，

SQL>startup mount;

6.在新的主库上把新产生的日志归档到新的备库

SQL>alter system archive log  current;

7.打开mrp进程应用日志，重演变化

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

5.查看状态：

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

至此将原来的主库成为了新的主的standby了。。。。。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29654823/viewspace-2649606/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29654823/viewspace-2649606/