这篇文章计划了一段时间，本来想写篇心情文字，还是留到周末再放飞心情吧。
今天的内容是关于数据库的备库的思考，当然我们可以自己问自己，我们的备库准备工作做好了吗？扪心自问，其实有些工作我也没有准备好，这是我的建议，其实一个备库的思考点还是有很多值得考量和斟酌的地方。自己也需要后续完善
备库总是在容灾中有着举足轻重的作用，但是故障难免，我们的备机备库是否能够在危机降临的时候顶住压力，这个需要打上一个问号，我会从硬件配置，系统层面，数据库层面，架构层面和网络层面进行一些分析。
硬件配置
备库硬件配置更差
这种情况比较普遍，很多时候备库的机器配置要比主库差很远，在没有问题的情况下，也是节省了资源，但是一旦问题发生的时候，就不单单是系统，数据问题了，性能问题也会迎面而来。对于高可用的业务来说，这个影响就会放大。
备库空间不足
如果主库的磁盘空间不足，数据增长受到了一定的限制，那么后面申请维护窗口之后，切换到备库之后，发现备库的空间也存在限制，那么这个时候就是把问题做了转移。
硬件故障
对于备库备机而言，硬件故障是个硬伤，有些情况下会出现，备机一重启就出问题，或者你申请了一台机器，结果本身就存在这潜在的硬件问题，那么这个时候备库还没来得及做切换已经自身难保了。
系统层面
备库在某种程度上还是有一定的设计弹性，对于环境的要求没有集群那么苛刻。但是有时候系统层面总是会有各种小问题，这些其实也都是可以尽量避免的。
操作系统不同
主备库的操作系统不同，这一点如果发现会很尴尬，但是对于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负载极高，那么这种情况下，只能是备库承载了一些额外的不必要的压力而已，这些部分还是需要改善，要不就很可能出现备库总是比主库还忙，备库更容易出现问题的情况。
大大小小列了这么多，也欢迎大家提出意见。