三分钟读懂Oracle数据库容灾架之DataGuard

Oracle数据库目前依然处于商用数据库的霸主地位。 运行在Oracle数据库上的核心业务及核心数据的安全性尤为重要。

目前市场上针对Oracle数据库常见的容灾产品大致可以分为两大类。

• Oracle 公司自己的容灾产品
• 非Oracle公司的容灾产品

Oracle公司目前的容灾产品有我们常见的DataGuard和属于中间件部门的Oracle GoldenGate(以下简称OGG)产品。非Oracle公司的有DSG迪思杰 及DDS九桥，这两种产品和OGG在实现原理上大致相同。

Oracle GoldenGate和DSG/DDS等产品，其license相对较为昂贵，而在购买了Oracle RDBMS软件license之后，DataGuard使用是免费的。Oracle 11g Active DataGuard(ADG)需要额外付费。

对于数据迁移，OGG/DDS/DSG 优势更明显。数据仓库数据大集中到Oralce中做数据分析 使用DataGuard 则显得太臃肿，不够灵活。OGG在对异构平台的数据迁移同步上也有显著的优势。同时也用于停机时间较短的数据迁移方案。 通过其初始化数据及后期的增量同步可以极大地减少业务迁移的停机时间。OGG的容灾同步可以满足多样性的需求，如只同步数据库的某个或几个用户下的数据。同时OGG可以实现多进程抽取，OGG 12.x版本支持从DataGuard备库中抽取数据到异地容灾数据库中。现在更推荐的架构是ADG+OGG 12.x从备库抽取数据到异地容灾机房。

在Oracle到Oracle的容灾方面，DataGuard在维护及预算支持上都优于Oracle GoldenGate。Oracle 11g Active DataGuard(ADG)备库实只读时查询可以支持报表业务，将主库的压力分散到备库上。11g的snapshot DataGuard将备库临时转换成一个可以读写的测试环境，数据完全和生产一致，为测试通过了一套最真实的仿真环境。测试完之后一键切回备库模式。测试数据自动抹去，不会影响数据的同步容灾。

这里插入稍微说一下Oracle的Extended RAC 容灾高可用。Extended RAC就是将传统的RAC两个节点从同一个机房改成分别放在两个不同的机房来实现单点容灾。然而考虑到RAC本身的一些问题及存储需求。RAC两个节点不能放置的距离太远(随着网络延迟的增加，RAC的性能成几何倍的衰弱，这就是为什么Exadata为什么将RAC所有节点放在同一个机柜的原因)，而距离太近又不能实现真正的灾备，如电网，台风，水灾，地震等等。同时需要存储复制的支持，预算将会是一个比较大的问题。

DataGuard 容灾的高可用性切换时间需要多久？ 在我们现有的客户环境中，DataGuard都是作为Oracle RAC的灾备环境。当RAC环境出现灾难性的损害彻底无法使用的时候可以通过一键failover脚本切换到备库。数据库本身在同步正常的情况下，切换可以在2分钟内完成。

关于DataGuard 和 OGG 在对网络带宽上的对比。DataGuard由于要传输比OGG更多的数据，其带宽占用要略多于OGG。但是也没有我们想象的那么恐怖。在正常的DataGuard同步中，oracle选择通过LNS将redo buffer中的重做数据推送到standby数据库中。这些其实是很小的一些量，对网络带宽的要求并不是很高。具体量的大小，可以通过业务高峰期间的awr报告中的load profile来大致分析。Oracle 11g配置DataGuard log_archive_dest_n属性中已经取消了arch/lgwr属性。 默认使用lgwr来传输。也就是说除非有GAP存在，Oracle DataGuard容灾本质上不再依赖归档日志。

Oracle 11g DataGuard 在实施上也比 10g 要方便很多。 通过Duplicate From Active DataBase备份不落地的方式复制数据库，可以在主库不停止的情况下直接实施DataGuard环境(前提是主库已经开启了归档模式，否则需要一次停机操作)。

如果需要使用ADG作为报表库，建议同时部署DataGuard监控。通过linux shell + oracle procedure实现监控ADG同步状态的脚本。可以监控出实时同步是否正常及延迟时间。