Oracle 11g Active Dataguard Failover实验
Dataguard是Oracle官方推荐MAA架构的重要解决方案。目前RAC+Local Dataguard + Remote Dataguard已经成为行业界普遍使用的HA架构方式。无论对于RAC还是Dataguard，实现switchover和failover都是最常用的操作场景。
Failover是一种“unplanned”切换动作。通常是主库Primary出现软硬件故障问题，不能够继续对外提供数据访问服务，就需要强制性的断开Primary，使用Standby来充当数据访问点。11g的Active Data Guard中，Standby通常是作为Read Only With Apply状态进行工作，提供出一个只读的数据访问来源，模拟读写分离的架构方式。在进行Failover之后，Primary库实际上是退出了Oracle HA架构体系，成为游离对象。Standby在切换之后就成为新的Primary。这个过程就是角色切换。
Switchover动作是不会引起数据丢失的，Standby可以保证接受并且应用所有的Redo Log数据。而Failover则不好说，根据不同的保护模式（Protection Mode），一个事务在主库上面是否被commit，是取决于standby上是否接受和应用上日志数据。所以，在进行Failover的时候，是可能会丢数据的。我们作为DBA，需要考虑的是在Primary站点site允许的情况下（因为Primary故障情况不明），尽可能的保护数据，减少数据丢失（Gap）。
本篇主要进行Failover过程的实验演示。
相关参考:
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端，手工去加载。