Oracle 11gR2(MAA) Physical Standby Database Failover

1、物理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中仅仅是最高的间隔。在解决间隔后，你必须重复这个查询直到间隔没有。