注意：故障转移会破坏DG的主从关系，使其变为互不相关的2个数据库，谨慎使用。
（一）故障转移操作流程图
（二）故障转移操作流程
备注：以下操作步骤与上面流程图步骤一一对应
STEP1：刷新所有未发送到备库的日志到备库
如果主库还可以启动到mount状态，则刷新所有未发送的归档日志和在线redo日志到备库。如果这一步成功了，则可以保证数据零丢失。
如果主库不能mount，则执行第2步。
使用如下命令刷新redo日志到备库:
SQL> ALTER SYSTEM FLUSH REDO TO 'target_db_name';
其中，target_db_name为备库的db_unique_name。
如果上面的语句执行成功，则直接跳到步骤5；如果执行报错，则执行步骤2。
STEP2：确认备库接收到的最新的归档日志文件
在备库上使用V$ARCHIVED_LOG视图，查询每个实例的最大日志序列号的日志，通过查询出的日志序列号与主库的最大日志序列号比较（主库的直接到服务器上去查看归档日志文件），可以直到缺失了哪些归档日志文件
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG; THREAD LAST ---------- ---------- 1 100
如果可能，对于还未传输到备库的日志文件，直接从主数据库上拷贝过去，然后注册日志，注册日志放入如下：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
STEP3：确认和解决日志GAP
在备库上查询V$ARCHIVE_GAP视图，确认是否存在日志GAP，如：
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 90 92
在这个例子中，GAP存在于线程1的90，91，92号归档日志上，如果可能，拷贝这些日志到备库服务器上，然后注册日志
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
STEP4：重复步骤3直到把所有GAP解决
继续在备库上查询V$ARCHIVE_GAP视图，直到没有数据返回，说明没有GAP。
如果在执行了步骤2到步骤4后，依然无法解决日志GAP（例如，主服务器宕机，我们无法访问主数据库，导致日志无法同步到备库），则执行failover切换后会存在数据丢失。
STEP5：备库停止日志应用
执行如下操作：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
STEP6：完成所有已经接收日志的应用
在备库上执行如下操作：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
如果这个操作未报错，则执行步骤7。
如果发生报错，尝试解决错误，再次执行以上SQL语句，如果报错无法解决，可以在目标备库执行以下语句来进行故障转移（会丢失数据）
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
这个语句完成后跳到第9步执行。
STEP7：确认目标备库准备切换为主库
查看目标备库v$database视图的SWITCHOVER_STATUS列
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY
如果SWITCHOVER_STATUS的值为“TO PRIMARY”或者“SESSIONS ACTIVE”，则说明备库已经准备切换为主库。如果不是这2个值，确认Redo日志应用是否还是活跃的，继续查询，直到变为这2个值中的一个为止。
STEP8：切换物理备库为主库
使用下面的SQL语句进行切换：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
STEP9：打开新的主库
SQL> ALTER DATABASE OPEN;
后续：
1.在打开数据库之后，建议做一个完整备份；
2.如果主服务器/数据库重新启动，则需要还原失败的主数据库。
【完】
|
相关文档： |