浅析Oracle 12c中Data Guard新特性

最新推荐文章于 2024-06-23 22:17:50 发布

aecuhty88306453

最新推荐文章于 2024-06-23 22:17:50 发布

阅读量193

点赞数

文章标签：数据库运维

原文链接：http://www.cnblogs.com/DataArt/p/9917962.html

版权

浅析Oracle 12c中Data Guard新特性

写在前面

无论是做Oracle运维的小伙伴还是老伙伴，想必对Oracle数据库的数据级灾备核心技术—Data Guard是再熟悉不过了！这项从Oracle 8i就开始大面积普及的数据复制与灾备技术以其久经考验的成熟性、易用性和可靠性，受到了Oracle DBA界的一致好评，曾经一度是HA和DR，甚至数据迁移时的首选技术。然而近年来业界涌现的一系列新型技术方案，如基于日志的逻辑复制技术和存储底层复制技术等，有在某些方面超越Data Guard的趋势，甚至越来越多的DBA相信这项火了十多年的技术也差不多快寿终正寝了。。。

不过Oracle就是这么任性，在大家都原以为会有颠覆性改变的12c版本中，不但保留了Data Guard作为数据灾备尤其是物理级灾备的核心地位，而且针对原有技术中的痛点，加入了若干实用又有趣的新特性，使之再次焕发出新的魅力！今天小编就带大家领略一下，在12c中Data Guard又给我们带来了什么~

没毛病

无需妥协

为两地三中心设计的Far Sync

近几年两地三中心已经成为大型成熟企业的标准灾备架构，而谈到灾备当然就离不开数据级灾备，对于Oracle数据库来说，就是Data Guard技术。然而架构师和DBA常常苦恼于Data Guard配置方案的权衡：如果采用SYNC同步传输模式，虽然备库与主库的同步会更紧密，遇到事故时数据保护的更好，但是毕竟对生产性能有一定影响，而绝大多数数据中心的首要任务是保障生产；但是如果配置为ASYNC异步模式，虽然对于主库的性能影响小了，但是备库与主库之间必然出现一定的延迟，这对于数据完整性要求很严格的交易类系统是比较严重的风险。而如果使用级联DG（Cascade Data Guard），又不得不在中转节点放置一整套存储来实现DG的搭建，存储的消耗与主库是一样的，这又是一定程度上资源的浪费。想必设计师只能在多种方案间权衡利弊，反复妥协，左右为难。

而在12c版本中，这个棘手问题的大救星终于来了，它就是Far Sync技术。

Far Sync

在Oracle 12c中，新增一种称为Far Sync的实例类型（instance type），如同rdbms和ASM实例，far sync本身就是一种特殊类型的实例，它不运行数据库，没有数据文件，而只有日志文件，是一种专门用于Data Guard配置中负责日志转发的轻量级实例。这个far sync实例需要配置在离主库距离不远的机房，例如同数据中心的其他机房或者同城灾备的机房，以便实现同步日志传输。

Far Sync实例的创建也是很简单的：

只需要拷贝主库的参数文件和密码文件，使用standby control file和standby redo logfile即可完成far sync实例的创建；由于far sync不运行实际的数据库，也就没有数据文件，对于存储的需求量是很低的。

然后我们就可以配置基于far sync的Data Guard架构了，如图所示，我们可以在主库（Primary）的附近搭建far sync实例，并在主库与Far sync，以及Far sync与远程的备库（standby）之间分别配置Data Guard。这里的far sync可以看做主库传输日志的一个destination，而备库standby又作为far sync的destination，类似于Cascade Data Guard，但是别忘了，far sync是没有数据文件的，只负责转发日志。

搭建完毕后，我们就可以开始Data Guard的日志传输了：在这个新式的配置中，主库与far sync之间采用SYNC同步传输模式，而far sync与备库之间采用ASYNC异步传输模式。这样做的好处大家应该也能猜到了：由于far sync离主库距离很近，所以SYNC模式不会造成什么性能影响，而且又保证了主库的日志可以得到灾备的保护；同时far sync实例再继续以ASYNC异步模式将日志传输到备库，由于far sync已经有了主库产生的全部日志，这些日志传输到备库只是时间问题，因此主库也不再需要苦苦地等待备库发送ACK回来才能commit事务，而是将后续的日志转发工作交给了far sync去完成，自己可以轻装上阵，保证生产。

值得注意的是，在12c中Oracle强烈推荐使用DG Broker完成DG的管理，尤其是对于多于一个备库的情况，如果不使用broker，那管理起来简直就是一场噩梦。复杂的拓扑结构和繁多的属性，如果没有使用broker获得一个自上而下的整体视图，会让管理员很快懵逼，而做切换的时候需要协调N多个实例和备库的角色关系，没有broker的话就几乎是mission impossible了！

一个配置完成的far sync结构如下图所示：（就是我们在broker中看到的）

从图中我们可以清晰的看到整个Data Guard的整体配置情况，哪个是主库，哪个是备库，哪个是far sync，一目了然。更重要的是我们在后续的修改属性和角色切换的时候，可以一键式管理，大大减轻了管理员的工作负担，减少了人为失误的可能性。这里要为DG broker这款工具点个赞！

中庸之道

最大可用模式中的FAST SYNC

来，敲黑板，我们先复习一下：在Oracle 11g中，DataGuard主要有两种日志传输模式—同步SYNC AFFIRM和异步ASYNC NOAFFIRM（当然还有ARCH模式，但是由于LGWR ASYNC的性能已经得到极大优化，ARCH模式已经不再推荐）。通常最大性能模式下使用ASYNC NOAFFIRM，即日志从主库传输出去之后就可以完成事务commit，而无需收到来自备库的确认ACK；而在最大保护和最大可用模式下使用SYNC AFFIRM，即必须保证每笔事务都正确传输到备库并写入磁盘，主库收到备库的确认ACK之后才可以完成提交，否则主库必须等待。

有一定DG维护经验的DBA会感觉到，最大可用模式作为一种介于最大性能和最大保护之间的折中模式，使用SYNC AFFIRM有些过了，多数情况下可能不需要牺牲这么大的性能来换取如此严苛的数据保护。因此12c给最大可用模式提供了一种称为 FAST SYNC的模式，也就是SYNC NOAFFIRM，主库与备库之间仍然以同步模式传输，但是主库只需等待备库收到日志即可，而无需进一步等待备库的日志写入磁盘才能提交，这就大大降低了性能的损耗，同时仍可以保证主库备库之间的数据同步。

FAST SYNC的配置也很简单：

我们可以在参数文件和DG Broker中实现FAST SYNC的配置

当然了FAST SYNC这个FAST也不是白来的，那么我们考虑一下，什么情况下FAST SYNC比SYNC的保护弱呢？我们知道，二者的主要区别在于是否等待备库收到日志后写入磁盘。那么答案也就显而易见了：如果主库故障之后，由于继发性故障或者纯粹运气不好，备库的内存信息没有来得及写入磁盘，那么内存中的最新日志信息就会丢失，造成数据不一致。所以是否采用FAST SYNC替代SYNC模式，就要看能否接受这个小概率事件的风险了。

升级神器

Data Guard rolling

作为一名DBA恐怕最害怕听见的词汇就是升级/迁移了---那意味着不知多少个不眠之夜，以及各种明处暗处的技术风险。Logical Data Guard作为一种常用的升级/迁移技术方案，因其可靠性高，停业时间短受到了DBA们的欢迎。但是这套方案的一个不足之处就是实施过程过于复杂，小编粗粗一算至少需要42个步骤才能完成一轮最简单的一主一备升级，如果涉及多套库，那这个复杂性会指数级地倍增。为了降低采用rolling技术升级的复杂性，减少人为失误可能带来的损失，oracle在12c中提供了新的DBMS_ROLLING包来帮助我们自动化地完成一系列升级任务。

DBMS_ROLLING包采用Specification—Compilation—Execution三步走的协议，只需DBA设置几个参数，即可自动实现后续的一系列配置、切换、启停库、验证等操作。在DBMS_ROLLING中有leading group和trailing group的概念，我们暂时简单理解为初始的备库和主库就好，实施的步骤包括初始化—设置参数—生成计划—验证计划—执行切换—收尾等过程。

之后继续调用DBMS_ROLLING.START_PLAN, DBMS_ROLLING.SWITCHOVER, DBMS_ROLLING.FINISH_PLAN这三个存储过程，即可实现自动化的切换升级。

DG Broker的Routing规则集

在最简单的一主一备配置中，日志的传输路由是显而易见的；但是如果Data Guard的配置涉及多个备库，尤其是我们上面提到的far sync，拓扑结构极为复杂，那么如果有效管理如此多的数据库的传输路由便成了令人头疼的难题。好在Oracle 12c的DG Broker为我们提供了Routing Rule这个新特性，可以傻瓜式地设置和管理多库环境下的传输路由。

我们假设Boston是主库，Cambridge是far sync，Chicago是物理备库，Shaumburg是反向far sync（切换后才工作），那么我们需要的路由便是：当Boston是主库时，日志先传输到Cambridge这个far sync，再转发到备库Chicago；而当切换主备库之后，新的主库Chicago将日志先传输到Shaumburg这个反向far sync，然后再转发到Boston。如果使用sqlplus中逐个修改参数的方法，不但容易出错，而且DBA也无法从整体上监控整个DG的完整拓扑；而我们现在使用DG Broker提供的Routing rule特性，只需简单的几条配置命令即可完成配置，还可以利用DGMGRL接口管理整个DG的配置信息：