Oracle Dg Broker Fast-Start Failover配置与应用管理
基本概念
Fast-Start Failover是建立在broker基础上的一个快速故障转换的机制，通过fast-start failover可以自动检测primary的故障，然后自动的failover到预先指定的standby上面，这样可以最大化的减少故障时间，提高数据库的可用性。Fast-Start Failover是在broker的基础上再增加了一个单独的observer，用来监控primary和standby数据库的状态，一旦primary不可用，observer就会自动的切换到指定的standby上面。
简单的说是当primary数据库down掉后，它会自动地快速执行切换standby数据库为primary数据库操作。
那么何时会发生fast-start failover呢，据官方文档介绍，当数据库以正常模式(shutdown immediate、shutdown normal、shutdown transactional)关闭时，系统不会触发fast-start failover的。下面的过程是使用shutdown abort关闭primary数据库的，所以这个操作触发了fast-start failover。在这里会用到observer，observer是用来监控primary数据库是否可用，当主库不可用时，系统会执行快速切换standby数据库为primary数据库。
官方建议observer不能与primary和standby数据库位于同一台主机,在另一台观察机器observer 上安装DGMGRL。就是安装一个Oracle 的客户端。 并在observer machine上配置相关的参数。包括配置监听， 使这台机器能访问主备库的实例。 然后通过这个observer来判断主备库的状态。 如果主库出现问了，那么observer 就会切换主备库。 放在另一台机器的原因也很明显，如果放在主库上，如果主库系统崩溃了，那么Observer也就失效了。
准备工作
确保broker配置为运行在Max Availability模式。
最高可用性（Maximum availability）：这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。
Maximum protection/AVAILABILITY模式必须满足以下条件：
（1）Redo Archival Process: LGWR
（2）Network Tranmission mode: SYNC
（3）Disk Write Option: AFFIRM
（4）Standby Redo Logs: Yes
（5）standby database type: Physical Only
即Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database; 如：
SQL> alter system set log_archive_dest_2='service=stoms lgwr sync AFFIRM';
注意： 主库的保护模式修改之后，备库的模式也会改变，和主库保持一致。
在此对LGWR 进程的SYNC 方式做下说明：
（1）Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
（2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。
（3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
（4） Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使用两种恢复方法：
实时恢复（Real-Time Apply）： 只要RFS把日志写入Standby Redo Log 就会立即进行恢复；
归档恢复： 在完成对Standby Redo Log 归档才触发恢复。
Primary Database默认使用ARCH进程，如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR 进程会抛出错误。如：
alter system set log_archive_dest_2 = 'SERVICE=STOMS LGWR SYNC NET_TIMEOUT=30' scope=both;
在primary和standby机器上都启用flashback database，这个在reinstate failed的数据库的时候要用。(必须)
在运行observer的机器上安装DGMGRL工具，用于启动observer。
配置tnsname.ora文件，保证observer能正常的连接到primary和standby数据库上面。
配置及启用Fast-Start Failover
在primary和standby数据库启用flashback
将Primary设置为flashback：(主库上操作)
SQL> select name, current_scn, flashback_on from v$database;
NAME CURRENT_SCN FLASHBACK_ON
--------- ----------- ------------------
OMS 130215396 NO
SQL> alter database flashback on;
数据库已更改。
SQL> select name, current_scn, flashback_on from v$database;
NAME CURRENT_SCN FLASHBACK_ON
--------- ----------- ------------------
OMS 130218094 YES
SQL> show parameter DB_FLASHBACK_RETENTION_TARGET;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 1440
SQL>
将standby设置为flashback：
在standby数据库上打开flashback之前，要先将standby数据库的intended state的状态更改为apply-off，primary数据库上不用操作。
GMGRL> show database stoms;
数据库 - stoms
角色: PHYSICAL STANDBY
预期状态: APPLY-ON
传输滞后: 0 seconds
应用滞后: 0 seconds
实时查询: OFF
实例:
oms
数据库状态:
SUCCESS
DGMGRL> edit database 'stoms' set state='apply-off';
SUCCESS
GMGRL> show database stoms;
数据库 - stoms
角色: PHYSICAL STANDBY
预期状态: APPLY-OFF
传输滞后: 0 seconds
应用滞后: 04seconds
实时查询: OFF
实例:
oms
数据库状态:
SUCCESS
在备库上操作：
SQL> select name, current_scn, flashback_on from v$database;
NAME CURRENT_SCN FLASHBACK_ON
--------- ----------- ------------------
OMS 130215396 NO
备库：需要先取消recover 进程，不然会报错
SQL>ALTER DATABASE FLASHBACK ON;
ORA-01153: an incompatible media recovery is active
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database flashback on;
数据库已更改。
SQL> select name, current_scn, flashback_on from v$database;
NAME CURRENT_SCN FLASHBACK_ON
--------- ----------- ------------------
OMS 130218094 YES
打开flashback之后，要将standby数据库的intended state的状态更改为apply-on。
DGMGRL> edit database 'stoms' set state='apply-on';
SUCCESS
GMGRL> show database stoms;
数据库 - stoms
角色: PHYSICAL STANDBY
预期状态: APPLY-ON
传输滞后: 0 seconds
应用滞后: 2 minutes 25 seconds
实时查询: OFF
实例:
oms
数据库状态:
SUCCESS
2、配置每个数据库Failover的目标，这一步是决定当数据库出问题之后会自动failover到那个standby。
DGMGRL> edit database oms set property 'FastStartFailoverTarget'='stoms';
已更新属性 "FastStartFailoverTarget"
DGMGRL> edit database stoms set property 'FastStartFailoverTarget'='oms';
已更新属性 "FastStartFailoverTarget"
DGMGRL>
3、配置和启用observer
首先创建一个observer.log文件，里面包含了系统切换信息：
[@oms ~]$ dgmgrl -logfile ./observer.log
DGMGRL for Linux: Version 11.2.0.1.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
欢迎使用 DGMGRL, 要获取有关信息请键入 "help"。
DGMGRL> connect
已连接。
DGMGRL> show configuration;
配置 - dg_oms
保护模式: MaxPerformance
数据库:
oms - 主数据库
stoms - 物理备用数据库
快速启动故障转移: DISABLED
配置状态:
SUCCESS
查看fast_start failover的状态：
DGMGRL> show fast_start failover;
快速启动故障转移: DISABLED
阈值: 30 秒
目标: (无)
观察程序: (无)
滞后限制: 30 秒
关闭主数据库: TRUE
自动恢复: TRUE
可配置的故障转移条件
健康状况:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle 错误条件:
(无)
DGMGRL>
启用fast_start failover和启动observer:
DGMGRL> enable fast_start failover;
Enabled.
DGMGRL> start observer;
observer started
DGMGRL>
现在可以通过tail –f observer.log查看observer的日志信息,可以看到observer started.
查看fast_start failover是否已经启用成功：
DGMGRL> show fast_start failover;
快速启动故障转移: DISABLED
阈值: 30 秒
目标: stoms
观察程序: oms
滞后限制: 30 秒
关闭主数据库: TRUE
自动恢复: TRUE
可配置的故障转移条件
健康状况:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle 错误条件:
(无)
DGMGRL> show configuration verbose
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
oms - Primary database
stoms - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 30 seconds
observer: orainst.desktop.mycompany.com
Current status for "FSF":
SUCCESS
也可用通过查询v$database视图，获取有关observer的信息.官方有如下解释:
如果observer不存在，会是如下结果：
如果observer启动失败，会产生以下ORA错误信息：
至此，fast_start_failover配置完成。
Fast-Start Failover管理测试
在启用了fast-start failover和observer之后，broker会来监控primary和standby数据库的状态，一旦primary数据库出现故障，observer会根据一定的程序来执行自动的failover操作。
当发生下列情形是observer会尝试启动failover操作
observer和primary数据库之间连接出现故障时
当primary数据库故障或者是RAC环境中所有instance都故障时
执行SHUTDOWN ABORT之后，特别注意正常的SHUTDOWN操作（NORMAL,IMMEDIATE,TRANSACTIONAL）不会引发failover操作
数据库文件OFFLINE。除了最后一个数据库文件OFFLINE的情形，其他的情况下observer都会尝试在FastStartFailoverThreshold制定的时间之内重新连接数据库，如果还是无法连接之后才会执行自动failover操作。
2、在FastStartFailoverThreshold指定的时间内重新连接数据库，在RAC环境中会尝试连接其他的instance。
3、尝试时间结束后，observer将确定目标standby可用。下面的这些情形会导致failover失败
fast-start failover没有启用
observer无法连接到standby数据库
standby与observer中记录的状态不一致
observer在primary fail的时候正好没有运行，再次启动之后只能找到一个standby
目标standby没有和primary完成同步
目标standby是逻辑standby时，在V$DATABASE中显示LOADING DICTIONARY时
目标standby还能和primary正常通讯时
在V$DATABASE的列FS_FAILOVER_STATUS中显示了其他无法进行failover操作时
有手工failover正在进行时
4、执行failover操作，使目标standby变成新的primary。
5、reinstate之前失败的primary
Fast-Start Failover具体测试过程
先看看当前的primary，确定是oms
DGMGRL> show configuration
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
oms - Primary database
stoms - Physical standby database
- Fast-Start Failover target
Current status for "FSF":
SUCCESS
然后登录到oms上，执行一个SHUTDOWN ABORT命令
[@oms ~]$ sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.1.0 Production on 星期二 5月 15 17:05:32 2012
Copyright (c) 1982, 2009, Oracle. All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>shutdown abort
ORACLE instance shut down
然后在observer里面可以看到自动failover了
DGMGRL> start observer;
observer started
17:08:24.47 Tuesday, September 01, 2012
Initiating fast-start failover to database "stoms"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "stoms"
17:09:33.49 Tuesday, September 05, 2012
再看此时的状态，primary已经换成stms了,不过此时oms是不可用的
DGMGRL> show configuration
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
oms - Physical standby database (disabled)
- Fast-Start Failover target
stoms - Primary database
Current status for "FSF":
Warning: ORA-16608: one or more databases have warnings
再将oms启动到mount，接着就能看到observer会自动的reinstate oms
DGMGRL> start observer;
observer started
17:11:13.45 Tuesday, September 05, 2012
Initiating reinstatement for database "oms"...
Reinstating database "oms", please wait...
Operation requires shutdown of instance "oms" on database "oms"
Shutting down instance "oms"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "oms" on database "oms"
Starting instance "oms"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "oms" ...
Reinstatement of database "oms" succeeded
17:12:20.07 Tuesday, September 05, 2012
查看Fast-Start Failover状态
通过SHOW CONFIGURATION VERBOSE命令可以查看Fast-Start Failover的基本运行状态
DGMGRL> SHOW CONFIGURATION VERBOSE
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
oms - Primary database
stoms - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 30 seconds
observer:
Current status for "FSF":
SUCCESS
要查看Fast-Start Failover更多的信息就要查看V$DATABASE视图中的相关的列了。
以下对参数说明：
FS_FAILOVER_STATUS | 这个列显示了Fast-Start Failover的状态，通过查看这个列可以知道数据库时处于什么状态之中，详细的状态信息在这里。 |
FS_FAILOVER_CURRENT_TARGET | 当前数据库的failover的目标数据库 |
FS_FAILOVER_THRESHOLD | 执行自动failover的时间超时值 |
FS_FAILOVER_observer_PRESENT | 是否启动了observer，通过查看这个列可以知道是否有observer在监控着这个数据库 |
FS_FAILOVER_observer_HOST | 监控此数据库的observer所在的位置 |
SYS@stoms>select FS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET, FS_FAILOVER_THRESHOLD,FS_FAILOVER_observer_PRESENT, FS_FAILOVER_observer_HOST from v$database;
FS_FAILOVER_STATUS FS_FAILOVE FS_FAILOVER_THRESHOLD FS_F FS_FAILOVER_observer_HOST
------------------------- ---------- --------------------- ---- ------------------------------
SYNCHRONIZED stoms 30 YES stoms
禁用Fast-Start Failover
禁用Fast-Start Failover的命令为
DISABLE FAST_START FAILOVER [FORCE]
加上FORCE之后将会强行在执行DISABLE命令的数据库以及这个数据库可连通的其他数据库上面上禁用Fast-Start Failover，而其他无法连接上的数据库将保持原来的状态；不加FROCE时如果有那个数据库暂时无法连接的话那么DISABLE操作将会失败。所以在当primary和standby数据库的网络连接良好的情况下要使用不带FORCE的命令。
通常需要使用FORCE的情形如下：
当因为网络问题造成primary无法和observer及那些已完成同步的standby通讯时，primary将会停止工作，如果primary的恢复时间可期，且想要primary继续工作的话就需要使用FORCE选项暂时在primary上禁用fast-start failover，不过之前一定要检查看数据库有没有自动failover。
当primary和standby没有完成同步的时候想要手工的执行failover的命令，在fast-start failover启用的时候是无法执行的，这时候也需要使用FORCE选项强行禁用fast-start failover。
在fast-start failover失败之后还想将数据库failover到其他可用的standby上时也需要先使用FORCE强制禁用fast-start failover然后在手工进行failover操作。
如果确定有问题的primary可以很快的恢复，此时不想让fast-start failover自动failover，也可以使用FORCE选项强行禁用fast-start failover。
Observer管理
启用observer的操作很简单，使用DGMGRL连接到数据库，然后执行START OBSERVER命令就行了。要启动observer的话必须使用SYS连接到DGMGRL，同一时间只能启动一个observer，如果尝试启动多个observer将会收到这样的消息
ORA-16647: could not start more than one observer
要停止一个observer的话只需要用DGMGRL连接到数据库，然后执行STOP OBSERVER命令就行了。
要确定一个数据库是否在observer的监视中必须要去查看V$DATABASE视图中的FS_FAILOVER_OBSERVER_PRESENT和FS_FAILOVER_OBSERVER_HOST。只有当FS_FAILOVER_OBSERVER_PRESENT为YES的时候才说明这个数据库时处于observer的监控之中。
同时数据库是否有observer监视这个信息也可以从DGMGRL中查看到：
DGMGRL> show database oms statusreport
STATUS REPORT
INSTANCE_NAME SEVERITY ERROR_TEXT
ERROR ORA-16820: Fast-Start Failover observer is no longer observing this database
在启动observer的时候，observer会自动的在当前目录中生成一个默认名字为fsfo.dat的二进制文件，这个文件里面保存了fast-start failover的配置信息，同时也包含了到primary和standby的连接方式。也可以在启动observer的时候使用FILE参数指定配置文件的位置，命令如下:
START OBSERVER [FILE=<observer configuration file>];
至此，整个fast_start failover配置过程结束。某些具体参数的意义请参考官方文档。
