在11g里面,Oracle认为最理想的情况是,虽然Oracle数据库不能打开,但是可以启动到 mount状态。
Mount状态之所以重要,就在于如果可以到这个阶段,控制文件control_file就可以读取 归档日志和在线日志的位置信息。这也就意味着最大可能性的进行数据恢复,避免数据损失。
在11g中,推出了日志手工flush的功能,来弥补日志数据没有传递的问题。
10g版本下没有办法自动flush redo。但是可以从Primary目录中,将日志拷贝到Standby端,手工去加载。
如果主库可以到mount状态,在11G里可以通过下面的命令,将未传送到standby端的日志传送过去:
alter system flush redo to ‘standby_db_unique_name‘;
既然是failover,主库已经处于down状态。查看备库的状态:
SQL> select name,open_mode,database_role,switchover_status from v$database; NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS ----- -------------------- ---------------- -------------------- ORCL READ ONLY PHYSICAL STANDBY NOT ALLOWED
查看是否存在未传送的归档:
select thread#, low_sequence#, high_sequence# from v$archive_gap; no rows selected
如果没有查到结果,说明归档在standby 端没有缺失。那么数据上基本不会有丢失,即使丢失,也只有 redo buffer 中未来得及刷出的部分可能会丢失。
:alter database register physical logfile ‘/arch/oradata/dg01/1_109900.arc‘;
将备库切换为主库.此时,我们不能通过cancel来取消数据同步,而是通过finish。 这个操作,实际上是关闭了MRP进程。可以通过alert日志来确认。
alter database recover managed standby database cancel; alter database recover managed standby database finish; # 终止进程后,查看备库的状态,如果是to_primary 说明可以进行切换 select name,open_mode,database_role,switchover_status from v$database;
# 切换 alter database commit to switchover to primary [with session shutdown]; # 查看切换后状态 select open_mode,database_role,switchover_status from v$database; OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS -------------------- ---------------- -------------------- READ WRITE PRIMARY FAILED DESTINATION
通过查询这个时间点儿的SCN,确定主备之间数据一致的点。 :SELECT to_char(STANDBY_BECAME_PRIMARY_SCN) from V$DATABASE;
将原主库启动,并闪回到上一步查询的scn点.
FLASHBACK DATABASE TO SCN &standby_became_primary_scn; #将原主库转换成物理备库,并启动日志应用进程 ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
alter database recover managed standby database using current logfile disconnect from session;
4.2 Oracle Dataguard failover 操作步骤
原文:https://www.cnblogs.com/halberd-lee/p/10639081.html