从摆脱Data Guard手工搭建及维护的烦恼说起

《从摆脱Data Guard手工搭建及维护的烦恼说起》要点：
本文介绍了从摆脱Data Guard手工搭建及维护的烦恼说起，希望对您有用。如果有疑问，可以联系我们。

讲师介绍

杨建荣

搜狐畅游高级DBA

DBAplus社群联合发起人.现就职于搜狐畅游,OracleACE-A、YEP成员,超7年数据库开发和运维经验,擅长电信数据业务、数据库迁移和性能调优.

持Oracle10GOCP,OCM,MySQLOCP认证,《OracleDBA工作笔记》作者.

本次分享将分为以下几部分：

• 半自动化搭建DataGuard
• 用不用DGBroker
• 几个实用场景演练
• 与时俱进：Oracle12cDataGuard改进
• 诊断案例：备库批量查询失败的案例分析
• 数据迁移中巧用DataGuard

一、半自动化搭建DataGuard

说实话,单纯搭建DataGuard的工作现在已经没什么技术含量了,而且手工搭建耗时,很可能会有很多的问题,所以我有个想法就是改进,也就是把它半自动化.

大体来说,搭建DataGuard有下面的一些问题：

• 搭建DataGuard看似工作量巨大
• 配置繁多(主库端,备库端)
• 问题琐碎(如果配置不当,很容易陷入各种问题漩涡)
• 规范化,标准化混乱,备库各有各的特点
• 主机名混乱
• Db_unique_name混乱
• 数据库参数不统一
• 主备的listener.ora,tnsnames.ora中的host有的用IP,有的用主机名
• Profile文件不统一

为什么是半自动化,初衷如下：

1. 就是为了安全
2. 主库就是主库,不要轻视任何微小的操作
3. 主库不规范的地方改动要谨慎
4. 备库不规范的地方改动要到位

半自动化的主要目标和套路如下：

安装前的配置占用70~80%的时间,所以半自动化的目标主要是配置,就是能简化配置,简化安装.

搭建备库的两种常用方式：

基于备库搭建备库

rman备份->restore->recover(10g)

基于duplicate的方式

在线搭建(11g)

说到这里有些羞愧,我自己在内部目前是使用这种方式,效果还不错,但是因为环境的差异,后期的脚本没有流程化,容错校验也不多,所以一直没有开放出来,近期会开放出来,大家保持关注吧.

二、用不用DGBroker

DGBroker是Oracle为DataGuard维护提供的一个很不错的工具,从我的实际使用来看,早期的版本中似乎大家都还是存在一定的思维定式,认为手工维护已经足够了.完全可以脱离开这些工具来直观的使用命令行的方式来维护,这个观点没错,不过存在一主多备的环境,环境较为复杂的情况,这样一个能够让你更轻松的工具,如果不用实在是太可惜了.

DGBroker在数据库端需要启用一个后台进程DMON来维护,这个后台进程启动,需要设置dg_broker_start为true即可,如果要停止,只需要设置这个参数为false即可.从系统资源的角度来考虑,那几乎可以忽略不计.

从搭建的便捷性上来看,DataGuard的搭建有了DGBroker已经几乎没有了技术含量.

当然DGBroker毕竟只是一个工具而已,如果不懂DataGuard的基本原理,不熟悉手工维护,那么还是先把那个坑踩平了再来玩这个工具.工具永远就是一个媒介.好与不好,明心自鉴,过度依赖工具与完全脱离工具,都是两个不可取的极端.

我是从手工的管理方式过渡到DGBroker的,上了这条船,其实发现还是值得的,所以有不少朋友也问我是否应该在生产环境中使用DGBroker,我的回答是放心用吧.上面我要讲的半自动化搭建主要就是希望用DGBroker的方式来完成最后的配置.

三、几个实用场景演练

1.如何演练Failover

有一天看到有一个网友提了一个问题,描述很简短：测试DG时,主库不能宕机,如何测试failover?

其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就希望在备库上做一下演练工作,而这个演练其实又不想影响到目前的主库,而且又希望能够尽可能模拟真实的情况,我想这样对于运维部门来说是最具有考核力度,而对于开发业务部门来说是最受欢迎的,因为他们什么都不需要改动.

而从技术角度来看,似乎有一些地方需要考量,如果备库Failover为主库,那么这个主库肯定是可以进行读写操作的,如果把它再切回备库,数据一致性怎么保证,怎么能保证是从上次的断点开始恢复.如果可以做,那真是一大福利.

我们先讲讲思路,还是闪回,但是闪回的玩法有一些差别,和reinstate的方式有一些区别.假设是一主一备的环境,备库开启了闪回数据库功能

我们不动原来的主库,把备库Failover为主库.

然后这个时候Failover的主库可读可写,当然最后还是要切换回备库接收归档,可以使用闪回,同时还需要切换角色,这个地方需要好好琢磨一番该怎么处理.

然后我们需要切换为备库,切换的命令就是关键,不是使用switchover的方式.
SQL> alter database convert to physical standby;

再举一个更极端的案例,做数据库的切换Switchover,然后发现了问题,需要回退,恢复到原来更早的状态,这个能不能办到,有了闪回,照样可以.

大体的思路就是下面的形式：

首先是一个主备库的环境：

switchover是计划内的任务,就是主切备,备切主.

这个时候发现切换出现了问题,我们需要紧急回退,需要回退到切换前的状态,要知道此时的主库已经不是原来的主库,备库也不是原来的备库了.闪回是否依旧可行,备库是否可以依旧选择一个新的断点可以重新同步?

（编辑：ASP站长网）