Physical Standby Database Failover
Physical Standby Database Failover1、物理standby failover 切换
故障转移时在一些糟糕的事情发生时执行的计划外事件，需要将生产库移动到DR站点。有意思的是，这时候人们通常忙来忙去，试图弄明白发生了什么，需要做些什么才能使数据库恢复过来。客户打来电话询问系统核实才能恢复，高级管理人员在走廊徘徊，追究是谁范了错误。对于DBA来说，没有什么事情比时空的备用站点更可怕，并且在需要备用站点前，我们也不知道它是否奏效。如果故障转移失败，DBA们将会失去奖金，甚至职业生涯因此中断。
所以我们在系统建立初期，就要有周密的后援计划。一旦出现问题，做到手不忙，心不慌。大显身手的时候到了。但此前需要有一番详尽实验做支撑，亲自动手很重要！
Step 1冲刷任何没有从主数据库发送到备用数据库的的重做
如果主数据库不能被Mounted，那可能就要将没有发送的归档和当前的日志从主库发送到备用数据库。如果这个操作时成功的，零数据丢失将是可能的，即使它没有在最大保护模式中。
确信redo apply是活动的在目标备用数据库上。
Mount,不要要打开主数据库。如果主数据库不能被mounted，跳至step 2.
执行如下SQL语句在primary database:
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
Target_db_name为目标备份库的DB_UNIQUE_NAME，它将会受到冲刷过来的重做。该语句只在11G R2中被支持。
如果该语句完成却没有错误，跳至step 5.如果执行过程出错，或者它没有有停下，因为你不能等待很长时间直到这个语句执行完，继续 step 2.
Step 2核实备份库中最近从主数据库发送过来的归档日志文件。
查询V$ARCHIVED_log视图在目标备份库中，获取每个线程实例归档过来的最大序列号。
例如：
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) over(partition by thread#) as last from v$archived_log;
THREAD LAST
---------- ----------
1 517
2 412
如果可能，拷贝每个主数据库归档重做日志到备份库，如果那些日志不在备份库上。并且注册它。它必须被做在每个重做线程上。
例如：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '<from your list>';
Step 3认定和处理任何的归档重做日志间隔（archived redo log gaps）
查询V$archive_gap视图在目标备份库上，决定这是否有任何的重做间隔。
For example:
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
可以看到存在重做间隔，需要线程1归档来的90、91、92号日志，如果可能，拷贝这些缺失的归档重做文件到目标重做数据库上。然后在每个线程节点上注册他们。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Step 4重复步骤3直到重做间隔被解决
步骤3中仅仅是最高的间隔。在解决间隔后，你必须重复这个查询直到间隔没有。
如果间隔没有被解决，一些数据的丢失将会丢失在故障转移期间。
Step 5停止Redo Apply
执行如下SQL语句在目标备份库上：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Step 6完成所有重做数据的应用
执行如下SQL语句在目标备份库上：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
如果该语句执行没有错误，行进到Step 7.
如果错误发生，一些接受到的重做数据没有被应用。尝试解决这些错误的原因并且重新确定这些错误状态在行进至下一步之前。
如果错误状况不能解决，故障切换也能进行（伴随一些数据丢失），执行下列SQL语句在standby databse：
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
此时是进行强制的切换，跳至步骤9,当这个激活状态被完成了。
Step 7确定目标备份库已经准备变成了一个主数据
执行如下语句确认数据库状态：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TOPRIMARY
1 row selected
如果这个值是TOPRIMARY或者SESSIONS ACTIVE表明主数据库是可以切换成Standby role的。如果是其他的值将不可以执行切换，
Step 8切换物理备份库到主数据库角色
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
Step 9打开新的主数据库
SQL> ALTER DATABASE OPEN;
Step 10备份新的主数据库
Oracle推荐对新的主数据库做一个全库备份。
Step 11在物理standby database上重启Redo Apply
For example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE -
> DISCONNECT FROM SESSION;
Step 12在可选择的情况下，重建失败的主数据库。
在故障切换后，源主数据库可能转换成一个物理standby数据库或者从新的主数据库的备份重建。
一旦源主数据库以Standby Role在运行，一次切换又可以把它重建回Primary role。
2、FAILOVER切换实录
SQL> alter system flush redo to 'HAINAN';
alter system flush redo to 'HAINAN'
*
ERROR at line 1:
ORA-16442: ALTER SYSTEM FLUSH REDO TO STANDBY succeeded, but some redo has not
been applied.
以上的步骤要花费N久的时间等待。
查看主备库上的alert日志：
主库上有大量的如下日志：
Fri Jul 12 11:23:22 2013
ARC4: Archiving disabled
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 is a potential flush redo target
LOG_ARCHIVE_DEST_2 is a potential flush redo target
备库上有如下的大量日志：
Fri Jul 12 11:23:30 2013
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Physical Standby applied all the redo from the primary.
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Physical Standby applied all the redo from the primary.
由此可见，应该是主库对备库的每个归档进行校验，要花费大量时间的。所
