杨建荣的学习笔记

《Oracle DBA工作笔记》签名版来这里:http://weidian.com/item.html?itemID=1896398398&p=-1

  • 博客访问: 11564793
  • 博文数量: 1117
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1000多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1117)

文章存档

2017年(49)

2016年(358)

2015年(360)

2014年(278)

2013年(48)

2012年(21)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题
你的备库做好准备了吗 2016-01-14 23:44:48

分类: Oracle

这篇文章计划了一段时间,本来想写篇心情文字,还是留到周末再放飞心情吧。
今天的内容是关于数据库的备库的思考,当然我们可以自己问自己,我们的备库准备工作做好了吗?扪心自问,其实有些工作我也没有准备好,这是我的建议,其实一个备库的思考点还是有很多值得考量和斟酌的地方。自己也需要后续完善
备库总是在容灾中有着举足轻重的作用,但是故障难免,我们的备机备库是否能够在危机降临的时候顶住压力,这个需要打上一个问号,我会从硬件配置,系统层面,数据库层面,架构层面和网络层面进行一些分析。
硬件配置
    备库硬件配置更差
这种情况比较普遍,很多时候备库的机器配置要比主库差很远,在没有问题的情况下,也是节省了资源,但是一旦问题发生的时候,就不单单是系统,数据问题了,性能问题也会迎面而来。对于高可用的业务来说,这个影响就会放大。

    备库空间不足
如果主库的磁盘空间不足,数据增长受到了一定的限制,那么后面申请维护窗口之后,切换到备库之后,发现备库的空间也存在限制,那么这个时候就是把问题做了转移。
    硬件故障
对于备库备机而言,硬件故障是个硬伤,有些情况下会出现,备机一重启就出问题,或者你申请了一台机器,结果本身就存在这潜在的硬件问题,那么这个时候备库还没来得及做切换已经自身难保了。

系统层面
备库在某种程度上还是有一定的设计弹性,对于环境的要求没有集群那么苛刻。但是有时候系统层面总是会有各种小问题,这些其实也都是可以尽量避免的。
    操作系统不同
主备库的操作系统不同,这一点如果发现会很尴尬,但是对于redhat和centos似乎还算兼容,但是跨度再大就会出现更多的问题了。
    没有主库的防火墙权限
在很多的容灾场景中,如果出现切换,很多情况下为了更纯粹,可能直接修改备库IP为主库的场景更多一些,那么备库是否含有主库的防火墙权限,切换过去之后,备库中还是需要保留这些信息的。要不切换之后,只能保证数据没丢,后续的都保证不了。
    操作系统版本差异
系统的版本不同,有时候会看到这样的系统版本搭配,redhat 6和redhat 4搭配,redhat 5和redhat 6搭配等等,这些也都算是遗留下来的。
    内核参数设置
这一点还是很容易被轻视的,备库的内核参数没有调优,当然对于数据同步是没有任何问题的,但是一旦切换,可能很多没有暴露出来的问题都会放大。

网络层面
网络心跳,网络带宽
    对于网络来说,其实也很重要,如果一个redo 文件好几个G,网络环境太差,老是可能丢包,那么对于备库的日志接收就会非常被动,而且可能出问题。
比如出现了问题,需要切换了,结果最新的一个归档还没有传过去,那么这种情况下就没法保证主备切换的时间了。
    没有同步的tnsnames.ora的配置
数据库中的网络层面的一些文件内容,比如tnsnames.ora还是最好需要主备的基本一致,对于客户端来说可能没有影响,但是对于服务端来说,可能就会丢失这些配置信息,如果做复核就会很麻烦。
    主备的监听端口不同
主备库的端口其实可以不同,但是最好还是能够基本的统一起来,不要为了更多的安全考虑把自己给绕进去了。这个也可以算是一个规范吧。
    备机的ILO不通
很多情况下,ILO对于我们处理一些硬件相关的问题还是非常有用的,但是如果备机出现了网络问题,而本身的ICMP的ILO服务就有问题,那么这台服务器就失去了连接重启的可能性,已经不可控了,业务切换过去只能更不可控。

数据库层面
备库是数据库层面的实现,但是数据库层面还是问题不少。
    主备的数据库软件存在差别
主备库的数据库软件,安装选项可能不同,这个情况下对于备库来说还是不够规范的,目前虽然没有发现存在什么问题,但是本身这类问题就很少见。发现了之后还是趁早矫正。
    参数不同 compatible
数据库层面主备库可以不一致,但是这种不一致就是潜在的风险和问题,怎么在后续做好兼容和特殊处理。
    备库没有temp表空间
备库的temp空间是可选的,当然没有对于备库而言也没有什么问题,但是在一些查询的时候就会报错,所以备库中还是把这个地方补上,不要等到开发同事告诉你查询报错了,或者temp比主库小很多的情况下,再来被动的处理要好很多。
    db link失效,不可用
主库中的db link在有些业务中还是需要的,而且也确实有一定的存在意义,但是如果在tnsnames.ora,防火墙层面引起关注,最终的问题就会表现为db link的问题。
    sga等参数设置问题    
主备库的sga的设置不同,在一定程度上也取决于内存或者内核参数的限制,最终反映到数据库层面就是一些内存参数大大不同。
11g的备库在mount阶段

架构层面
在架构层面其实也有很多考量的地方,或者设计上有一些潜在的问题。
    同一台机器上有dg还有逻辑备份
如果一个备库,同时有dg,同时每天还要做一次逻辑备份,其实对于这个备库而言,工作量还是蛮大的,尤其消耗比较大的就是逻辑备份。
    一台机器上有多个备库
如果一台机器上有多个备库,有两种场景比较让人纠结,一种是主库挂掉,切换过去,结果有一主和另一个业务的备库在同一台机器上,就会非常纠结。
另一种情况就是如果备机出现问题,那么搭建备库就需要搭建好几个备库。
    dg broker可以作为参考,不能完全依赖dg broker
dg broker是个好工具,但是很多时候发现越依赖它,发现有时候它其实没那么给力,有些场景下还是不能很好的校验,尤其是10g的dg broker。
而且如果存在主库的归档被删除的情况,那么备库中RFS接受归档然后过期删除,dg broker是校验不出来的,它只会认为存在gap,但是检查点都是正常的。
    备库不是简单的接受应用归档
这一点非常重要,如果在早起的版本中,没有了adg,其实备库的作用就非常有限,有了adg这种情况就需要改善了。从开始设计的时候就可以为备库考虑更多的业务角色,比如报表查询,比如批量查询等等。
应用层面
    cpu负荷更高
应用层面理解其实也很容易,11g的adg其实已经有了更多的责任,如果在备库中存在着大量的问题sql,导致了备库的cpu负载极高,那么这种情况下,只能是备库承载了一些额外的不必要的压力而已,这些部分还是需要改善,要不就很可能出现备库总是比主库还忙,备库更容易出现问题的情况。

大大小小列了这么多,也欢迎大家提出意见。
阅读(6497) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册