Data Guard实现故障自动切换（二）(r11笔记第40天)
今天下午我的一个朋友碰到了一个Data Guard的问题，大体是主备网络出现问题，因为环境中配置了自动切换，结果备库就自动切换为了主库，这样就成了“双主”，我帮忙看了下，对备库做了闪回，然后直接转换主库为备库角色，一个看似繁琐的修复工作就完成了。
在一个一主多备的环境中，的确需要一个强大的工具来支持，所以最后朋友说DG Broker真是个好东西，我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。
就如同我昨天文章
我们先来示范一下，看看它的好，然后说说它的限制和改进之处。
首先就是DG Broker最基础的两个命令了。
第一个命令是创建配置，添加主节点
DGMGRL> create configuration dg_dataguru as启用一下配置
DGMGRL> enable configuration;第二个命令是添加备库节点
DGMGRL> add database sdataguru as剩下的命令都主要是围绕这两个命令来服务的，查看一下配置成功后的信息情况。
DGMGRL> show configuration;MaxPerformanceFast-Start Failover: DISABLED正如红色字体标识的，目前的主备是在最大性能模式下，我看很多文章说要配置Fast-Start Failover需要在最大高可用模式下，这是错误的，实际上在最大性能模式和最大高可用模式下均可。
DGMGRL> enable fast_start failover;查看oerr ora 16651你会看到一屏幕的提示信息，把要点都说全了。我点几个主要的点
1.主备库需要开启闪回数据库
主库开启在open状态下即可，非常方便，至于为什么主库需要开启，主要是作为reinstate来铺垫的，是故障自愈的一个环节。
SQL> alter database flashback on;
SQL> recover managed standby database cancel;2.主备库的网络配置
一个简单的listener.ora的配置如下：
LISTENER =DATAGURU_DGMGRL)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;查看状态的信息如下,有几点需要注意的就是我们可以设置Lag Limit，Observer Reconnect等属性。
DGMGRL> show fast_start failover;Lag Limit: 30 secondsShutdown Primary: TRUEAuto-reinstate: TRUEObserver Reconnect: (none)Observer Override: FALSE
在此你可能对故障自愈没有深刻的体验，我们就来实验一下。
主库直接shutdown abort
22:36:07.60 Tuesday, January 10, 2017可以清晰的看到，是做了Failover的操作。
我们只需要把数据库启动到mount阶段，然后静观日志变化。22:37:34.67 Tuesday, January 10, 2017
就这样一个看似复杂的reinstate工作就自动修复了，无需手工干预和处理。
当然你要说这个过程中还有什么特别的研制，数据库层面来说，这种方式是非常好的，可以在这个基础上去借鉴更多的有点和细节之处。
而这个方案的一个瓶颈就在于这个完全自动化的部分，如果出现了误判的情况，可能这时候问题就会很尴尬，会导致一些数据库切换的难解问题。
从实践的角度和通用的角度来说，我们需要定义更多的规则和逻辑。这种方式可以作为一种非常好的参考理念。