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博客 ” ，链接：https://blog.itpub.net/29654823/viewspace-2649606/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
