共计 3818 个字符，预计需要花费 10 分钟才能阅读完成。
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 了。
