今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。
在一个一主多备的环境中，的确需要一个强大的工具来支持，所以最后朋友说DG Broker真是个好东西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。
就如同我昨天文章Data Guard故障自动切换的想法(r11笔记第39天)所说，自动切换也是故障自愈的一个关键环节。而其中Oracle自带的Fast-Start
Failover就是一个相对不错的选择，如果你的环境网络层面做了统一的管理规划，只关注数据层面的自动切换，这个自带的方案其实很强悍，完全可以实现一些较为复杂的自动化切换需求。
我们先来示范一下，看看它的好，然后说说它的限制和改进之处。
首先就是DG Broker最基础的两个命令了。
第一个命令是创建配置，添加主节点
DGMGRL> create configuration dg_dataguru as
> primary database is dataguru
> connect identifier is dataguru;
Configuration "dg_dataguru" created with primary database "dataguru"启用一下配置
DGMGRL> enable configuration;
第二个命令是添加备库节点
DGMGRL> add database sdataguru as
> connect identifier is sdataguru
> maintained as physical;
Database "sdataguru" added
DGMGRL> enable database sdataguru
Enabled.剩下的命令都主要是围绕这两个命令来服务的，查看一下配置成功后的信息情况。
DGMGRL> show configuration;
Configuration - dg_dataguru
Protection Mode: MaxPerformance
Databases:
dataguru - Primary database
sdataguru - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS正如红色字体标识的，目前的主备是在最大性能模式下，我看很多文章说要配置Fast-Start Failover需要在最大高可用模式下，这是错误的，实际上在最大性能模式和最大高可用模式下均可。
如果要开启Fast-Start Failover，单单使用enable选项是不够的。
DGMGRL> enable fast_start failover;
Error: ORA-16651: requirements not met for enabling fast-start failover
Failed查看oerr ora 16651你会看到一屏幕的提示信息，把要点都说全了。我点几个主要的点
1.主备库需要开启闪回数据库
主库开启在open状态下即可，非常方便，至于为什么主库需要开启，主要是作为reinstate来铺垫的，是故障自愈的一个环节。
SQL> alter database flashback on;
Database altered.
备库开启闪回数据库略有不同，大体步骤如下：
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database flashback on;
Database altered.
SQL> recover managed standby database disconnect from session;
Media recovery complete. --最后的步骤或者使用enable database的方式也可以2.主备库的网络配置
这个其实根据我的了解，绝大多数的系统中都是会忽略掉这个配置，因为对于基本的Switchover,Failover来说也够用了，所以有的同学也会偷懒不配置了。
一个简单的listener.ora的配置如下：
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = newtest.oracle.com)(PORT = 1521))
)
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = dataguru)
(ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
(SID_NAME = dataguru)
)
(SID_DESC =
(GLOBAL_DBNAME=DATAGURU_DGMGRL)
(ORACLE_HOME = /U01/app/oracle/product/11.2.0.4)
(SID_NAME = dataguru)
)
)重点就是红色的部分，基本格式就是<DB_Unique_Name>_DGMGRL
配置后要确保监听的服务正确注册了，重启对应的监听保证服务使用无误。
备库的配置也是类似的形式，就不重复贴出了。
2.主备延迟，Failover的一些触发条件
设置数据库的切换优先级，可以配置FastStartFailoverTarget
如果我要设置数据库sdataguru的Failover对象为dataguru,就可以使用如下的命令。
edit database sdataguru set property FastStartFailoverTarget=dataguru;
如果主备的设置为最大高可用保护模式，则需要设置LogXptMode为sync
如果主备的设置为最大性能保护模式，则需要设置LogXptMode为async
启用FastStart Failover
DGMGRL> enable fast_start failover;
Enabled.
DGMGRL> start observer ;
Observer started查看状态的信息如下,有几点需要注意的就是我们可以设置Lag Limit，Observer Reconnect等属性。
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold: 30 seconds
Target: dataguru
Observer: snewtest2.cyou.com
Lag Limit: 30 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Observer Reconnect: (none)
Observer Override: FALSE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle Error Conditions:
(none)
在此你可能对故障自愈没有深刻的体验，我们就来实验一下。
主库直接shutdown abort
DG Broker中的observer的日志如下：
22:36:07.60 Tuesday, January 10, 2017
Initiating Fast-Start Failover to database "sdataguru"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "sdataguru"
22:36:16.52 Tuesday, January 10, 2017可以清晰的看到，是做了Failover的操作。
对于故障自愈，如果主库已经修复，可以正常启动，那么就会自动触发由主库调整为备库，也就是我们开头所说的reinstate.
我们只需要把数据库启动到mount阶段，然后静观日志变化。
22:37:34.67 Tuesday, January 10, 2017
Initiating reinstatement for database "dataguru"...
Reinstating database "dataguru", please wait...
Operation requires shutdown of instance "dataguru" on database "dataguru"
Shutting down instance "dataguru"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dataguru" on database "dataguru"
Starting instance "dataguru"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "dataguru" ...
Reinstatement of database "dataguru" succeeded
22:38:24.08 Tuesday, January 10, 2017
就这样一个看似复杂的reinstate工作就自动修复了，无需手工干预和处理。
当然你要说这个过程中还有什么特别的研制，数据库层面来说，这种方式是非常好的，可以在这个基础上去借鉴更多的有点和细节之处。
而这个方案的一个瓶颈就在于这个完全自动化的部分，如果出现了误判的情况，可能这时候问题就会很尴尬，会导致一些数据库切换的难解问题。
从实践的角度和通用的角度来说，我们需要定义更多的规则和逻辑。这种方式可以作为一种非常好的参考理念。