搜狐畅游高级DBA:Data Guard运维中的实战经验和技巧

杨建荣 2016-07-15 10:17:07
本文根据第64期线上分享整理而成。

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

  1. Data Guard的灾备介绍

  2. 备库的设计方案考虑

  3. 备库敏感的几个数据文件类操作

  4. 对Switchover和Failover的建议

  5. SQL审核之Snapshot Standby

  6. Data Guard搭建/重建的小技巧

 


写在前面


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


Data Guard的标准写法


补充一句,对于很多Oracle DBA,这个名词的写法和用法我见过很多: dataguard,dg,Datagurad,Data Guard等等。在此纠正一下,标准用法应该是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硬件配置


(1)备库硬件配置比主库差


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


(2)备库空间不足


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


(3)硬件故障


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


2系统层面


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


(1)操作系统不同


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


(2)没有主库的防火墙权限


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


(3)操作系统版本差异


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


(4)内核参数设置


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


3网络层面


(1)网络稳定性带宽


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


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


(2)没有同步的tnsnames.ora配置


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


(3)主备库的监听端口不同

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


(4)备机的iLO不通


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


4数据库层面


(1)主备的数据库软件存在差别


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


(2)参数compatible不一致


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


(3)备库没有temp表空间


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


(4)DB Link失效,不可用


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


(5)SGA等参数设置问题    


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


(6)11g的备库在mount阶段


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


5架构层面


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


(1)同一台机器上有DG还有逻辑备份


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


(2)一台机器上有多个备库


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


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


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


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


(3)备库不是简单的接收应用归档


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


6应用层面


备库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导致。


create tablespacetestdata datafile '/DATA/app/oracle/oradata/test04/testdata01. dbf' size 100M;

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


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


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


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


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


4、Drop datafile导致的bug


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


Bug 5623467 - Corrupt redo from ALTER TABLESPACE DROP DATAFILE (文档 ID 5623467.8)


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


五、对Switchover和Failover的建议


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




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


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


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


六、SQL审核之Snapshot Standby


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


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


    七、Data Guard搭建/重建的小技巧


    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天的精华选集,今天分享的内容部分出自书中,希望大家多多捧场,学习交流,共同进步。


    Q&A

    Q1:直接DG Broker建备库?能够分享下这个文档, 一直把DG Broker当管理用。

    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通过网络来同步,搭建起来也很省事。


    作者介绍  杨建荣


     
    精选专题(点击蓝色标题可阅读全文)

    最新评论
    访客 2023年08月20日

    230721

    访客 2023年08月16日

    1、导入Mongo Monitor监控工具表结构(mongo_monitor…

    访客 2023年08月04日

    上面提到: 在问题描述的架构图中我们可以看到,Click…

    访客 2023年07月19日

    PMM不香吗?

    访客 2023年06月20日

    如今看都很棒

    活动预告