本次分享由以下几个部分组成：

之前有一个朋友很有深意的问我Data Guard和RAC哪个更重要，前提是在高可用和容灾两者之间来选择，只能选其一，我是毫不犹豫选择Data Guard,毕竟这是数据安全的基本防线，我想Data Guard的命名（中文翻译为数据卫士）也是这个用意吧。当然Oracle的MAA架构中是包含了RAC和Data Guard，也是作为官方推荐的最佳实践。

补充一句，对于很多Oracle DBA，这个名词的写法和用法我见过很多: dataguard，dg，Datagurad，Data Guard等等。在此纠正一下，标准用法应该是Data Guard。

Data Guard可以理解为对于主库的一个完整镜像,只是主备库的角色不同，在灾难切换时能够做主备切换(SwitchOver),故障转移(FailOver)，如果对于容灾的工作不够重视，墨菲定律就是对这种情况的无形诠释，一旦灾难发生，尤其是发生自然灾害，不可抗因素的情况下，容灾往往是最后的救命稻草。

而数据库的容灾有多重要呢？来看一下下面的数据。

据美国德克萨斯州大学的调查显示，只有6%的公司可以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。

Gartner公司的一项调查表明，在灾难之后，如果无法在14天内恢复信息作业，有75%的公司业务会完全停顿，43%的公司再也无法重新开业，20%的企业在两年之内被迫宣告破产。

所以根据行业规范和标准，一般公司都会根据系统的重要程度，根据RTO、RPO的要求制定相应的数据库备份和容灾规范，如金融行业保监会、银监会、证监会都下发了明确的规范规定RTO、RPO时间。关于RTO和RPO的级别可以参考如下。

• RTO从低到高分为5个级别，其中1级为最高级别，如下图：

• RPO从低到高分为5个级别，其中1级为最高级别，见下图：

而具体一些，容灾就是为了保证数据不被丢失，根据统计，数据丢失的场景有以下几种。

可以看到前两项几乎占有了绝大多数的比例，尽管硬件和系统错误能够预防，人为错误还是防不胜防。

在此我抛出一个问题，你的Data Guard环境达标吗？

备机/备库是否能够在危机降临的时候顶住压力，这个需要打上一个问号。下面将从硬件配置、系统层面、网络层面、数据库层面，架构层面和应用层面进行一些隐患分析。

（1）备库硬件配置比主库差

这种情况比较普遍，很多时候备库的机器配置要比主库差很多；在没有故障的情况下，看似节省了资源，一旦问题发生，就不仅仅是系统和数据的问题了，性能问题也会随之而来。对于高可用的业务来说，这个影响就会放大。

（2）备库空间不足

当主库的磁盘空间不足，数据增长受到了一定的限制时，需要申请维护窗口，或者切换到备库，就会发现备库的空间也存在着限制，这个时候就是简单把问题做了转移而已。

（3）硬件故障

对于备机备库而言，硬件故障是个硬伤；某些情况下，备机一重启就出现问题；或者你申请了一台机器作备机备库，结果本身就有潜在的硬件问题，那么这个时候备库还没来得及做切换已经自身难保了。

备库在某种程度上还是有一定的设计弹性的，要对于环境的要求没有集群那么苛刻。但是有时候系统层面总是会有各种小问题，这些其实也都是可以避免的。

（1）操作系统不同

主备库的操作系统不同，这对于Red Hat和CentOS似乎还算兼容，但是如果跨度再大就会出现问题。

（2）没有主库的防火墙权限

在很多的容灾场景中，如果出现切换，为了更方便，可能直接修改备库IP为主库的场景更多一些，那么备库是否含有主库的防火墙权限，切换过去之后，备库中还是需要保留这些信息的。不然切换之后，只能保证数据没有丢失，后续的都无法保证。

（3）操作系统版本差异

系统的版本不同，有时候会看到这样的系统版本搭配，RedHat 6和RedHat 4搭配，RedHat5和RedHat 6搭配等，这些也都算是遗留下来的问题，还是要尽量做到版本一致为好。

（4）内核参数设置

这一点很容易被轻视，如果备库的内核参数没有调优，这对于数据同步是没有任何问题的，但是一旦切换，可能很多没有暴露出来的问题都会放大。

（1）网络稳定性带宽

首先是稳定性。如果一个redo 文件达到几个GB的大小，网络环境太差，可能丢包，这样对于备库的日志接收就会非常被动，而且可能出现问题。

其次是带宽。比如，出现了问题，需要切换，结果最新的一个归档还没有传过去，那么这种情况下就没法保证主备切换的时间了。

（2）没有同步的tnsnames.ora配置

数据库网络层面的一些文件内容，比如，tnsnames.ora最好是主备基本一致；对于客户端来说，可能没有影响，但是对于服务端来说，可能就会丢失这些配置信息，丢失之后的恢复会很麻烦。

（3）主备库的监听端口不同

主备库的端口虽然可以不同，但是最好还是能够统一起来，这个也可以算是一个基本规范。

（4）备机的iLO不通

很多情况下，iLO对于我们处理与硬件相关的问题还是非常有用的。如果备机ICMP的iLO服务有问题，那么这台服务器就失去了连接重启的可能性；无论是其本身还是业务切换之后都会变得不可控。

（1）主备的数据库软件存在差别

主备库的数据库软件，安装选项可能不同，这是不太被关注的地方，虽然这类问题就很少见，但发现了之后还是趁早矫正。

（2）参数compatible不一致

数据库层面主备库虽然说可以不一致，但是这种不一致就是潜在的风险和问题，应考虑好如何在后续做好兼容和特殊处理。

（3）备库没有temp表空间

备库是否需要temp空间是可选的，如果没有，对于备库而言没有什么问题，但是在操作某些查询时就会报错，所以备库中还是把这个地方补上为好，不要等到开发同事告诉你查询报错了，或者temp比主库小很多的情况下，再来被动的处理。

（4）DB Link失效，不可用

主库中的DB Link在有些业务中还是需要的，而且确实有一定的存在意义；但是如果在tnsnames.ora和防火墙层面未引起注意，最终的问题就会体现在DB Link上。

（5）SGA等参数设置问题    

主备库的SGA设置不同，在一定程度上也取决于内存或者内核参数的限制，最终反映到数据库层面就是一些内存参数巨大差异。

（6）11g的备库在mount阶段

这种场景其实还是蛮纠结的，在11g环境中，如果不能充分利用ADG的特性，要么是不了解这个特性，要不就是不作为。

在架构层面其实也有很多需要考量的地方，甚至有些设计上的潜在问题。

（1）同一台机器上有DG还有逻辑备份

如果一个备库，不但有DG，每天还要做一次逻辑备份，对于这个备库而言，工作量还是蛮大的，尤其消耗比较大的就是逻辑备份。

（2）一台机器上有多个备库

如果一台机器上有多个备库，有两种场景会让人纠结比较，一种是主库宕机，切换过去，结果有一主库和另一个业务的备库在同一台机器上，就会非常纠结。

另一种情况就是如果备机出现问题，那么就需要搭建好几个备库。

这时DG Broker可以作为参考，不能完全依赖DG Broker。DG Broker在有些场景下还是不能很好地校验，尤其是10g的DG Broker。

而且如果存在主库的归档被删除的情况，那么备库中RFS接收归档然后过期删除，DG Broker是校验不出来的，它只会认为存在GAP，但是检查显示是正常的。

（3）备库不是简单的接收应用归档

这一点非常重要，在早期的版本中，没有ADG，其实备库的作用就非常有限，自从有了ADG后这种情况就改善很多了。因为从开始设计时就以为备库考虑了更多的业务角色，比如报表查询和批量查询等。

备库CPU负荷更高。

这一点从应用层面理解其实也很容易，11g的ADG其实已经有了更多的责任，如果在备库中存在着大量SQL的问题，导致了备库的CPU负载极高：在这种情况下，备库只是承载了一些额外的不必要压力而已。这个问题还是需要改善，不然就很可能出现备库总是比主库忙，也会导致备库更容易出现问题。

用存储行业的话来说，现在存储正在从被动变为主动，但是总体上是被软件抢了风头，RAID被ASM抢，快照被Flashback抢，DR被ADG抢。

这话听起来蛮有意思，其实在行业内，对于容灾有很多的解决方案，在10g及以前，我之前从事的电信行业中使用BCV比较普遍，但是后来也都大量使用了Data Guard,其中的一个重要原因就是Active Data Guard,即备库在只读状态下依然可以接收应用归档，这一点非常难得。

而备库的设计方案也有很多的考量。

这是最基本的一主一备设计。

这里有几个地方需要考虑。

1. 容灾。如果主库挂掉，备库能够进行Failover（故障转移），11g的备库现在被赋予了更多的责任，一主一备可以支持。

2. 批量查询。如果备库批量任务压力较大，本身对于CPU资源消耗较大；如果长年累月，本身硬件消耗就不可忽略；如果长此以往可能出现了问题切过来也不见得保险，这个暂定。

3. 人为操作的防范。如果出现了误操作和人为操作，是否能够及时合理的预防，是否选择延时，也是两难，这个也暂定。

所以我们在条件允许的情况下考虑一主两备。一般来说一主两备都是一主一备在同机房或者同城，备库2在异地或者异机房。

对于这种方案，要考虑修复人为错误的可能，有很多系统都会设置延时，类似这样的形式：

如果延时是2个小时，3个小时前出现了问题，那这种场景就会有局限性了。

所以我们可以考虑闪回数据库的方案。把一些业务做一些切分，尽可能分担压力。

我们考虑一个极端情况，同城机房两台机器崩溃的情况，而且更为严重的是在崩溃的前一分钟，出现了人为误删除操作，那么异地灾备将会如何呢？

这个时候备库2就可以重新接管了，把身上的包袱都卸下来。

当然Data Guard不是灾备的“万金油”，也有适合的场景，现在OGG也有不少的灾备应用场景，点到为止。

我们来说说Data Guard环境中数据文件处理的几个小问题。

1、主库创建表空间后，备库MRP无法启动

在主库创建表空间或者是添加数据文件是一个很普遍的操作，如果下面的语句运行后，备库的归档应用进程（MRP）异常，则很可能是standby_file_management为MANUAL导致。

还是因为主备端的路径不一致导致，建议还是设置为AUTO。

2、主库设置表空间ONLINE,OFFLINE

如果在主库端设置表空间为ONLINE,OFFLINE,在备库是无法感知这些信息的，这种情况下就会出现两段的状态不一致（比如备库dba_data_files的bytes字段为空），而修复方式就是从控制文件入手。

3、数据文件中的特殊字符

这类问题我碰到过一次，花费了不少的时间去排查。而究其原因就是在数据文件末尾包含了一个空格，这个情况下很容易把自己带入死胡同，而解决方法就是要细心，严谨。

4、Drop datafile导致的bug

这个坑我踩过，也手工修复过。在10.2.0.4版本中主库添加数据文件，然后删除数据文件，会有ORA-00600的问题，可以参考

当然官方建议是重建备库，其实在尝试了一番，发现也可以手工修复。

其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节，也是非常关键的处理过程，我们需要加快切换时间，就有需要考量的地方。如下图所示。

除了数据之外，还有很多的配置信息需要考虑，有些需要完全同步，有些需要选择性同步。从配置的角度而言，Switchover和Failover的差别很小，对于备库来说都是透明的，只是一种数据库角色标示。

我们可以简化switchover和 Failover的一些内容，其实从操作上来说，主要的区别就是是否修改IP, switchover可能会替换IP, 而Failover可能会修改备库IP 为原来的主库IP，而我的建议就是大家在listener.ora,tnsnames.ora中尽量使用主机名来配置，那样的话在/etc/hosts中只需要配置一次IP即可，修改还是保留IP，只在/etc/hosts中即可完成，就不用逐个在配置文件中一一修改了。

当然退一步而言，主库端需要谨慎操作，不要在线修改主机名，但是主库端不能轻易改动，备库更应该做好这些工作。

这个特性对非常牛叉，如果是ADG是备库可读可应用在线数据变更，已经很给力了，那么Snapshot Standby可是备库可读可写，当然可以切换的，内部原理还是用到了闪回数据库。我觉得这一点可以充分利用到SQL审核中。

现在行业内也有不少的SQL审核工具和平台，这个特性本身并不能进行审核，只是可以利用可读可写的特点进行验证，而依靠ORA报错的SQL审核局限性很大，逻辑问题和性能问题都很难发现， Snapshot Standby可以对大多数的逻辑和性能问题辅助审核。

1. 如果说搭建备库会让你感觉步骤繁琐，验证啰嗦，强烈推荐你使用DG Broker,这是Oracle原生支持的工具，11g里面的很多细节已经做得很好了。

   我对10g中的DG Broker有一点不满意之处就是，备库在READ-ONLY状态时，DG Broker检查都是通过的，如果备库忘了开启日志应用，很可能归档被删除了，大多数情况下得重建备库来修复

2. 如果主库误删除了归档没有同步到备库，在数据量很大，数据变化不大的情况下，可以通过在主库RMAN做增备，恢复到备库来完成跳归档恢复，避免重建备库的繁琐。

3. 在一主多备的环境中，可以考虑Cascade Standby，当standby与primary的距离较远需要通过WAN来传输Redo时，为减少传输过程中对primary的压力及网络带宽的占用，仅让其中的一个standby从primary直接接收redo，当然还有一个限制就是只适用于Physical Standby。

4. 自11g开始，Oracle开始支持有限制的跨平台配置Data Guard.

   具体参考官方在Data Guard 中对异构主备系统的支持（Doc ID 1602437.1）

最后为个人的新书做一个宣传，《Oracle DBA工作笔记》是我个人学习笔记连续800天的精华选集，今天分享的内容部分出自书中，希望大家多多捧场，学习交流，共同进步。

A1：使用DG Broker搭建备库，绝大多数的场景下你不需要特意配置log_archive_dest的的设置了。DG Broker会帮你打理好。

Q2：1主2备的情况下，可以设置1个备为sync一个为defer吗？

A2：可以的，我在分享中也提到了。这种方式会有一些局限性。

Q3：如何判断dg完全正常，从哪些视图查看？

A3：1.DGBroker可以查看，show configuration是一个基本验证，show database verbose xxx可以看到更细节的信息，11g里的配置实在是太全了。不过不要过度依赖DG Broker

2.通过在主库端查看动态性能视图，我喜欢在主库端监控这个视图

selectTIMESTAMP,FACILITY, SEVERITY, MESSAGE 

fromv$dataguard_status

whereSEVERITY='Error' and timestamp > sysdate-xxx/24/60

Q4：备库硬件配置差，这个好像不好解决，备库绝大多数时候都像球队上的替补，通常是没有主力那么大能力，也不知道有没有调查数据，看看通常做法是啥，或者根据行业不同来确定配置，金融银行可能是相同的硬件配备，其他的可能是弱配置，或者0.75规模的配置？

A4：主备硬件配置这个有实际情况，ADG可能会缓解原来备库“不中用”的现象,内核参数的部分，让我想起了一个深刻的故事，主备环境除了操作系统内核版本不同，其它配置几乎一样，结果尝试了十几种方法，一一排除，最后发现是一个内核相关的bug,ORA-1578 ORA-353 ORA-19599 Corrupt blocks with zeros whenfilesystemio_options= SETALL on ext4 file system using Linux (Doc ID 1487957.1)

Q5：杨老师，能说说一些Dg的日常监控项吗？或者您的博客里有这样的文章吗？

A5：对于DG的日常监控，可以参考我说的两种思路，可以通过shell来定制DG Broker的输出，或者使用动态性能视图v$dataguard_status（主库端监控即可），基本够用了。

Q6：接着第二个问题，1主带2备，1个为sync，1个为defer，（您的回答为可行，我有点不太理解），protection_mode为MAXIMUM AVAILABILITY，难道不是两个备都是sync的吗？怎么控制另外一个为defer的呢？

A6：在最大高可用模式下的归档延迟情况，我还真没有测试过，目前为止我还没有实际用过这个模式。最大性能模式下是可以的。

Q7：做同步对网络延时有什么要求？

A7：对于网络问题，这是个很现实的问题，个人觉得一个就是设置归档大小，不能太大；还有一个就是通过归档的参数设置，有net_timeout之类的设置可以根据自己的情况来调整；还有一个就是网络层的调整，网络差了很多问题都是瓶颈。

Q8：一主两备怎么实施？有实际的案例吗？

A8：一主两备的的实际案例有很多啊，核心系统都是一主两备，异地或者异机房。实践起来还是有一定的技巧的，数据量大，可以考虑通过备库1来搭建备库2，即备库1 做rman备份，然后在备库2恢复;如果数据量不大，直接可以duplicate通过网络来同步，搭建起来也很省事。

作者介绍  杨建荣