相关参考:
1、实验环境说明
我们依然使用ora11g和ora11gsy配对节点。Primary为ora11g，Standby为ora11gsy，两边版本均为11.2.0.4。
先启动ora11gsy，启动standby端。
[oracle@SimpleLinux ~]$ export ORACLE_SID=ora11gsy
[oracle@SimpleLinux ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 21 21:27:28 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 372449280 bytes
Fixed Size 1364732 bytes
Variable Size 331353348 bytes
Database Buffers 33554432 bytes
Redo Buffers 6176768 bytes
Database mounted.
Database opened.
启动apply过程。
--Standby端启动后默认为Read Only。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
之后启动Primary端。
[oracle@SimpleLinux ~]$ env | grep ORACLE_SID
ORACLE_SID=ora11g
[oracle@SimpleLinux ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Tue Apr 22 15:26:29 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1364340 bytes
Variable Size 272633484 bytes
Database Buffers 33554432 bytes
Redo Buffers 6307840 bytes
Database mounted.
Database opened.
2、Failover实验
我们人工模拟Primary崩溃，直接关闭。
SQL> shutdown abort
ORACLE instance shut down.
真实环境下，Primary的故障是多样的，现象也是多样的。最彻底的就是Primary站点直接失去联系，不能访问。这种情况出现并不多，但是也能出现。比如磁盘（非冗余）损坏、断电、地震天灾。最简单的情况也许是监听器停止工作需要重启、实例停止等等。
故障的多样，也就意味着恢复的机会是多样的。在11g里面，Oracle认为最理想的情况是，虽然Oracle数据库不能打开，但是可以启动到mount状态。
Mount状态之所以重要，就在于如果可以到这个阶段，控制文件control_file就可以读取到，归档日志和在线日志的位置、信息都可以读取到。这也就意味着最大可能性的进行数据恢复，避免数据损失。
在11g中，推出了日志手工flush的功能，来弥补日志数据没有传递的问题。
SQL> startup mount
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1364340 bytes
Variable Size 272633484 bytes
Database Buffers 33554432 bytes
Redo Buffers 6307840 bytes
Database mounted.
进行日志刷新：
SQL> alter system flush redo to 'ora11gsy';
System altered.
此时，alert log中显示信息，将日志传递。
Tue Apr 22 15:31:00 2014
Resetting standby activation ID 4239920854 (0xfcb80ed6)
Tue Apr 22 15:31:00 2014
Archived Log entry 14 added for thread 1 sequence 27 ID 0xfcb80ed6 dest 1:
Media Recovery Waiting for thread 1 sequence 28
Tue Apr 22 15:31:00 2014
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Physical Standby applied all the redo from the primary.
检查日志gap的问题，可以查看视图v$archive_gap。
SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;
no rows selected
如果没有发现明显的gap现象，说明此次的failover不会有数据损失情况。在standby端，要进行关闭apply和结束应用动作。
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database recover managed standby database finish;
Database altered
SQL> select open_mode, switchover_status from v$database;
OPEN_MODE SWITCHOVER_STATUS
-------------------- --------------------
READ ONLY TO PRIMARY
注意：这个过程并不会经常成功执行，而且在10g这样的版本下也没有办法自动flush redo。解决的方法也是有的，就是从Primary目录中，将日志拷贝到Standby端，手工去加载。