闲扯Dataguard的维护与运用

Dataguard从9i起就在oracle的高可用和容灾方面发挥着巨大的作用，尤其是物理dg，整体来讲，部署容易，管理相对简单，运行比较稳定，是企业高可用架构中承担举足轻重的角色。
   10g physical dataguard同9i 版本相比，整个风格还是一脉相承的，调整增加了一些功能和参数以便于更平滑的切换和更可控的故障切换。另外，在日志的传送机制上，也有了相应的优化改进。
   不管是小到十几G的db，还是大到T级别的db，架构dataguard都是一套理想的软件层面的高可用方案。它能避免数据库主机的单点隐患，有效的提高业务系统的服务时间，能够在短时间内完成计划内的切换和计划外不可预计的故障切换。
   在我所在的企业环境中，大面积的采用了物理dataguard来作为数据库服务器应急方案(以下就物理dg谈)。

1.健壮性

   Dataguard是相当健壮的产品，一般搭建好环境后，不容易破坏。运行会出现一些故障，但都容易fix。除非你的归档日志由于规划问题或者人为原因丢失而断档(少数bug情况除外)，一般情况下整个dg环境无需重建。
   另外，无论是数据库小版本之间的升级/打patch还是类似9i到10g跨大版本升级，只要操作合理，整个dg环境都能保持，无需重建。

2.稳定性

   物理dataguard具有极高的稳定性。因为dg需要通过网络对archivelog或者redo进行transprot，因此网络的稳定和带宽往往较其他方面会对整个dg的性能和稳定运行产生影响。糟糕的网络环境和IO会带来一些特定的dg环境的等待事件，对主库性能和运作造成影响。例如较高的wait on等待(ARCH wait on SENDREQ/ATTACH/DETACH||LGWR wait on SENDREQ/ATTACH/DETACH||LNS wait on SENDREQ/ATTACH/DETACH)，可先从网络方面入手诊断，当然，在高负载的环境中，这种dg等待还是会时常出现的，大部分并不是网络带来的问题。

3.高可用迁移

   应该说，对于同平台的db迁移(同版本或者跨版本)，物理dataguard对其具有强大的杀伤力，不论你的数据库容量多大，采用dataguard做迁移都能将停机时间控制在几小时或者几分钟之内。而且，因为不涉及数据库辑对象层面的变更，整个过程风险小，考虑的因素少，即便不小心失败也不会对现有的环境造成破坏。

转自：

http://www.easyora.net/blog/dataguard_chitchat.html