从块结构谈数据库容灾

的，容灾建设比较马虎吧。正巧此时一个金融行业的客户打来求助电话，他们接到上级部门的通知，要进行容灾演练，而在切换容灾系统时，却发现系统中一套10g 版本的Oracle 数据库无法启动。后来问题解决了，其实很简单，他们的容灾环境采用的是IBM 的SVC 复制，但是只复制了数据库相关的文件，并未同步操作系统的系统目录中的文件，而且host 文件的配置也是错误的，

所以才导致数据库无法启动。这个问题虽然不大，却暴露出另一个问题，就是容灾平台疏于管理，当主生产环境变更时，没能及时变更容灾环境。在这些年的工作中，老白亲自经历过三次容灾切换，其中两次成功，一次失败。成功的两次都是切换到本地容灾系统，而失败的那一次则是切换到远程容灾系统。

先说说成功的那两次吧。当时客户要为系统添加RAC 第三节点，由于存储容量不足，无法满足第三节点UNDO 表空间和归档目录的需求，因此决定扩充一个由16 块硬盘组成的扩展柜。由于集成商经验不足，新扩展的盘柜和磁盘的微码与原系统不兼容，扩容工作很不顺利。原定于周五晚上添加RAC 节点，周四必须完成磁盘扩容工作，但是从周三就开始的盘阵扩容进行了一

天半还是毫无进展。于是IBM 的售后服务人员也加入了此项工作，经过诊断，他们建议现场插拔一下磁盘。在反复了几次后，磁盘突然整个锁死，系统无法正常工作了，而这时正好是下午5点多，系统业务最高峰的时段。

经过我和客户技术主管的讨论，我们决定马上切换到容灾系统。当时此系统有两套容灾系统，本地容灾采用DATAGUARD 技术，远程容灾采用类DATAGUARD 技术将归档日志压缩后传输到远程进行注册和应用。远程容灾系统在离故障点100 多公里以外的城市，配备了两台IBM P561服务器，而本地容灾系统只是利用剩余设备搭建的一个备份平台，其目的并不是为了容灾，而是为了减轻备份对生产系统的负载。它只包含一台IBM P561 服务器，且仅配备了48 GB 的内存，此配置与生产环境两台配备了72 GB 内存的P570 系统相比，处理能力明显不足。按照常理，在这样的情况下，切换到异地容灾系统是比较合理的，但是经过仔细分析，当时并不具备这样的条件，因为只有主生产系统在异地建立了容灾系统，而其余十多个外围系统并未建立相应的异地容

灾系统。一旦将主生产系统切换，那么就需要更改上千个配置项才能够完成全业务的切换，而这项工作并无现成的预案和操作脚本，仅凭人工操作，很难保证系统正常切换。另外还有一个更大的问题，在远程容灾机房中，仅配备了几个初级的系统管理人员，并未配备专职DBA 等维护人员，一旦进行切换，大家只能在远程操作系统，很难确保切换过程不出问题。

如果切换到本地容灾系统，只需要将DATAGUARD 服务器的IP 改为生产环境的IP，然后激活DATAGUARD 即可完成，而且维护人员还可以在本地进行操作。不过最大的问题是本地的硬件配置明显不足以支撑生产环境50%的业务。于是我建议将生产环境上的部分内存插到容灾系统的服务器上。这个主意似乎很不错，但是由于生产环境采用的是P570 服务器，而本地容灾系统

采用的是P561 服务器，大部分从P570 上拔下的内存条并不能在P561 上使用。于是只能又在备件库房凑了凑，才凑够了42 GB 内存，将容灾服务器的内存扩充到了90 GB。在随后重启容灾服务器的过程中，又碰到了网卡不能自动激活的问题，总之经过一系列的处理，终于在一个半小时后恢复了系统的运行。虽然本次切换最终成功了，不过由于业务高峰期系统停止了近100 分钟，大量业务被积压，并影响了货物通关，最终导致了惊人的损失。

在这次事故中，投入大量资金的异地容灾系统并未发挥应有的作用，反而是不在规划中的DBA 的无心之作解救了这次危机。这个案例也暴露出了此容灾平台建设中的问题，这些问题其实是普遍存在的。第二个案例差不多是2002年的事情了，这个客户采用的容灾技术和第一个案例不同，是采用存储级复制技术，容灾平台配备了70%的处理能力。那次老白正好在客户现场进行另外一套系统的优化。由于生产系统的存储突然掉电，大量的数据文件损坏了。当时客户还很淡定，因为他们投入巨资建设了先进的容灾系统，而且这套容灾系统在几个月前还做过切换演练。但是容灾系

统启动时，其中的一台数据库服务器启动不了，从错误信息来看，是由ORA-704 和ORA-600 错误引起的。当值DBA 忙碌了几个小时还是没办法解决问题，突然想到这边还有一个做优化的DBA，于是就请我帮他解决。现在看来，那个问题其实并不难，主要是由于UNDO 表空间存在坏块才导致数据库无法正常启动，通过_offline_rollback_segments 和_allow_resetlogs_corruption 参数，再辅以BBED，强制打开数据库就有可能解决问题。不过那时老白的技术还比较差，整整折腾了一天也没能解决。由于客户建设了容灾系统，就没有再建设备份系统，因此这个系统没有可用的备份集，最终老白只能祭出dul 这个法宝，导出了数据并重建了整个数据库。虽然最终大多数数据被恢复了，不过整个业务却中断了5 天之久。

和10多 年前不同，现在的容灾系统建设已经成为一种主流，一般来说，核心的业务系统都会建设容灾平台。不过和10 年前类似的是，现在的IT 部门决策者还是不了解容灾技术的本质，因此在选择容灾平台的策略上，仍存在很多误区。如果不能真正从原理上理解容灾技术的本质，那么就无法保证容灾切换失败的悲剧不再重演。

目前的主流容灾技术包括下面几种：

•  存储同步复制技术；

•  存储异步复制技术（包括各种类型的存储复制以及卷复制）；

•  Oracle DATAGUARD；

•  逻辑复制技术（比如STREAMS、GOLDENGATE、DSG 等）；

•  应用级数据复制技术。

存储同步复制技术也就是平常所说的镜像（mirror）技术，一个写I/O 必须在本地和容灾系统上同时完成写操作才算操作完成，任何一个写错误都将导致整个写I/O 失败。这是一种十分严格的同步机制，因此能够确保容灾平台的数据随时都是可用的。这项技术是十分成熟的，甚至Oracle 都专门提供了一套解决方案——RAC on Extended Distance Clusters，就是一套远程的RAC系统，两个节点不共享一个磁盘阵列，而是共享两个互为镜像的磁盘阵列，每个读写操作都会发送到两个磁盘阵列上。一旦某个地方出现故障，那么另外一个地方的系统还可以独立工作。这是一种兼顾RAC 高可用和异地容灾的解决方案。虽然目前在国内还缺乏成功案例，但是其技术成熟度已得到验证。不过采用镜像技术的系统，一旦某个存储出现故障，必须尽快隔离，否则就会影响系统的运行，因为一个I/O 操作必须同时成功才能够完成。存储异步复制技术目前在容灾系统上的应用十分广泛，这种方式既提供了易于维护的高效容灾复制，又避免了备用存储故障导致生产系统无法正常工作的问题。但是如果深入研究这种容灾技术的本质，我们还是会发现其中潜在的风险。为什么会碰到这样的案例呢？这个问题在10 年前曾使老白十分困惑，不过随着对Oracle 内部结构的认识，特别是对数据块结构的认识，老白终于明白了，导致当年那个问题的最根本原因就是“块断裂”，其产生的根源在于Oracle 的数据块和操作系统的数据块大小不一致。一般的UNIX 系统，其磁盘块的大小是512 B，而Oracle 的数据块大小是8 KB，也就是说，一个Oracle 数据块包含了若干个磁盘块。从Oracle 数据块的定义上来看，虽然Oracle 的数据块分配的磁盘空间是连续的，但由于底层存储条带技术，系统不能确保Oracle 数据块在磁盘上是连续分布的，甚至一个Oracle 数据块有可能被存储在多个磁盘中。由于Oracle 数据块和操作系统磁盘块之间的不同，就产生了一种可能性：一个Oracle 数据块被操作系统分成了多个I/O 写盘，这些I/O 之间的时间点是不同的，因此在某个瞬间，远程容灾系统上数据中可能包含了一个数据块的某个部分的变更，但是缺少了其他部分的变更，这就导致该数据块中的各个组成部分是不一致的。通过块头和块尾以及校验和的比较，就能发现数据块处于不一致状态。这种情况的表象就是Oracle 读到了坏块，也就是我们常说的块断裂现象。这就是为什么使用存储异步复制技术的容灾系统，在数据库打开后经常会发现坏块的原因。如果坏块正好出现在UNDO 表空间中，或者出现在一些关键的系统数据字典表中，那么在打开这个数据库时就可能会出现问题。对于一般的系统，块断裂发生的几率并不是太高，但是对于数据变更十分频繁的7×24 系统来说，出现的几率会大得多。之所以那个客户在容灾演练时没有发现问题，主要是因为客户在此期间通常会停掉业务，这样数据库就处于相对的静态，出现问题的几率很小，而实际生产系统故障需要切换时往往是业务高峰，出现块断裂的可能性几乎是100%。这类容灾技术有很多，主要的方案提供厂商包括EMC、赛门铁克（赛门铁克采用卷复制技术）、飞康、HP、IBM 等。原厂的工程师总会宣称他们的算法是经过严格认证的，能够确保容灾系统上的数据完全复制自生产系统上某一瞬间的数据，并且在时间点上肯定是一致的，因此不存在不可用的问题。这个说法看似很有道理，不过仔细考虑一下，好像还是存在漏洞。时间上的一

致性，就能确保数据库的一致性吗？要解决这个问题，就需要认真研究数据库一致性的条件。我们假定有一个一致性的存储快照（snap），在这个快照上，没有任何一个数据块是断裂的，那么我们认为这个快照是一致性的；反之这个快照是非一致性的，在这种情况下打开数据库，可能就会出现坏块。如果坏块出现在SYSTEM 表空间或者UNDO 表空间中，数据库甚至可能无法打开。即使某个快照是一致的，数据库就一定能打开吗？在进行数据库介质恢复时，如果在某个SCN停止了恢复，系统提示某些文件还处于不一致状态，此时打开数据库会出现故障，这种情况下，即使RECOVERPOINT 和SCN 是完全一致的，数据库中的某个数据文件也可能存在问题（可以通过V$DATAFILE_HEADER 的FUZZY 字段来判断是否有文件的FUZZY 是“Y”，这个视图的数据是从文件头中读取的），这时打开数据库，某些数据文件可能就会出现坏块，如果是SYSTEM或者UNDO 表空间的文件中存在坏块，那么数据库打开后，有可能还是会因为ORA-600 错误而无法正常工作。

从这一点，老白想到了几年前和几个赛门铁克的工程师讨论他们的基于卷复制的容灾平台。当时的生产库是一套10g RAC 和一个逻辑STANDBY 实现的报表系统，需求是当容灾发生时，系统可以顺利切换并且报表系统的逻辑STANDBY 还能继续工作，也就是说容灾系统上的生产库和报表系统之间的逻辑STANDBY 必须能够继续保持关系，这就要求切换的时候两个系统还要保持SCN 的一致性。起初，赛门铁克的工程师也认为他们的产品是无懈可击的，后来经过测试发现，切换时经常会有坏块出现。虽然如此，他们总是能够从中找到一个时间点，在这个时间点上做切换总是可以完全恢复。实际上，这个案例从侧面印证了老白的观点，由于SCN 在时间上的不连续性，导致一部分时间点的数据是一致的，而另一部分时间点的数据是不一致的。因此采用类似技术的容灾系统，不论其技术如何先进，都存在相同的隐患。既然存储复制容灾容易出现块断裂，那么它是不是就没有用武之地了呢？这是不能一概而论的。随着存储复制容灾技术的不断改进，现在的技术又有了新的发展。为了提高存储容灾系统启用时的可用性，可以在每天业务量不是很高的时候，对主要表空间设置BEGIN BACKUP 状态，然后做一个快照，再设置为END BACKUP。一旦激活容灾系统时出现了ORA-704 或者ORA-600

这样的错误，就可以从那个时间点通过归档日志RECOVER DATABASE 恢复数据，从而获得一个可用的数据库。

在官方文档Supported Backup, Restore and Recovery Operations using Third Party SnapshotTechnologies [ID 604683.1]中，Oracle 提出了一个不需要BEGIN BACKUP/END BACKUP 也能实现一致性复制的设想。这篇文章往往令很多存储厂商认为，自己的存储产品是不使用BEGIN BACKUP/END BACKUP 就总能够在容灾系统正常打开数据库的。因为Oracle 的官方文档中有这么一句：Oracle will officially support the following operations assuming that the third party snapshot

technology can meet the prerequisites listed in the next 2 sections.（Oracle 支持下列操作，只要第三方快照技术符合下面两节里列出的前提条件。）

不过如果你继续阅读下面的前提条件：

第三方快照前提条件

第三方厂商需要保证其快照符合如下要求：

• (1) 与Oracle 推荐的上述恢复操作完好集成；

• (2) 数据库在快照点上一致性宕掉；

• (3) 快照中对每个文件的写顺序加以保留。

就会发现这种场景对快照的要求十分苛刻。第一点和第三点比较容易实现，目前EMC 的SRDF、HDS 等产品都支持根据写顺序的数据复制。而第二点“数据库在快照点上一致性宕掉”是十分苛刻的。在真正的容灾环境下，有可能总是能幸运碰到这种情况吗？很多客户在测试类似的容灾平台的时候，总是通过突然杀掉生产库的实例来验证容灾是否起效，这么测试肯定是百分百的成功，因为这种情况对于容灾库而言，就像是数据库实例宕掉后重启一样。如果你尝试在生产库直接关掉存储（包括备用电池），这种情况下，你的容灾库是否还能很幸运地启动呢？我想如果这样，你真的十分幸运。为了解决这些问题，各种技术也是层出不穷，其中最为著名的是飞康公司的CDP产品，这个产品称为持续数据保护产品，就是说不是简单的复制IO，而是把主存储的IO截获后发送到备端，先用一个缓冲池保存起来，然后再异步复制到备端。如果备端出现问题的时候，还可以通过IO回滚，回到之前的某个事态。这种机制确实能够解决上的问题，不过这带来另外一个问题，就是IO捕获对主生产存储的影响，以及IO缓冲区的容量，以及给运维带来的复杂性。由于上面的几个问题飞康解决的并不好，CDP在国内的很多用户处的使用效果并不理想，这个产品也在2016年停止发展了。

Oracle DATAGUARD 是一种适合本地容灾的解决方案，由于DATAGUARD 是基于Oracle 数据块的复制技术，它不会造成块断裂，因此很适合本地容灾系统使用。DATAGUARD 的缺点是，如果采用LGWR 同步模式，一旦DATAGUARD 出现故障，将导致生产库也无法使用；而如果采用LGWR 异步模式或者ARCH 传输模式，一旦主库故障，丢失的数据量可能会多于存储复制技术的丢失量。除了上述几种常见的数据库容灾技术外，近年来，又出现了以Oracle GOLDENGATE、DSG、Oracle Streams 为代表的逻辑复制解决方案。这些解决方案基本上都是通过对Oracle 日志进行挖掘，将逻辑变化记录捕获后传输到目标端，转换为SQL 语句，并应用到目标数据库，从而实现数据同步。目前已经有很多用户使用这些产品建立了自己的容灾平台。这种容灾手段避免了数据块断裂的问题，在某些场合下是适用的。不过这种基于逻辑复制的技术存在一个很大的缺点，就是无法有效控制数据复制的延时，对源端的系统依赖较大，而且对大批量数据维护工作有较严格的限制。而这些逻辑复制产品，对于大事务的控制都存在一定的缺陷，比如，生产环境做了一个UPDATE 操作，修改了2000 万条记录，这个操作在生产环境中可能10 分钟就完成了，

而在目标端，该操作就变成了2000 万个独立的UPDATE 语句，执行完成这些UPDATE 操作，可能需要几个小时，甚至更长的时间，这样就会造成复制的延迟。如果这时生产系统出现故障，那么恢复业务可能需要较长的时间，甚至有可能出现一些更为严重的问题。比如对于GOLDENGATE 来说，其捕获进程在某个事务没有提交时不会捕获数据，只有当事务提交时才会捕获，如果某个事务执行的时间比较长，那么捕获进程会等待该事务提交，这样就会产生较

大的延时，如果这时系统出现故障，就会出现大量没有来得及捕获的数据，这些数据可能会彻底丢失。针对大事务，GOLDENGATE 进行了一定的优化，比如对于INSERT 操作，GOLDENGATE会自动合并类似的语句，采用BULK INSERT 的方式处理，这种方式已经被证明是十分有效的，对于批量插入操作的复制效果很好。不过对于UPDATE 和DELETE 操作，上述处理方式并没有

实现。系统是复杂多变的，实际环境并不总是以我们个人的意愿而改变。

只有了解了主要复制技术的基本实现原理，我们才能在设计自己的容灾平台时选用正确的方案。逻辑复制技术对于数据量不大，很少有大事务的系统是有效的，但如果将其用于容灾系统，就需要加强对系统运行状况的监控。通过心跳表监控可以及时发现延迟增大问题。在一个逻辑复制环境中，目标系统出现性能问题，或者目标系统中某个不合理的查询，都有可能让复制延时变得很大（老白以前甚至还碰到过由于没有及时在目标环境中进行表分析而导致复制进程采用了错

误的执行计划，从而使得复制延时变大）。另外，在逻辑复制环境中，应尽可能保证目标服务器的性能，从而避免复制延时。

DATAGUARD 适用于本地容灾，对于一些数据变化比较大的系统，传输大量的归档日志需要很高的网络带宽。存储级别数据复制技术由于传输的仅仅是存储数据的变化， 其传输数据量小于DATAGUARD，因此很适合在广域网上进行数据复制。这种复制模式很适用于异地容灾平台。对于不同的应用，不同的SLA，选择合适的容灾技术十分关键。在本地建立DATAGUARD本地容灾系统，远程使用基于存储复制技术的远程容灾系统，也许是不错的选择。最后聊聊这两年兴起的CDM（COPY DATA MANAGEMENT），这个最初由美国安特飞公司提出的数据管理机制实际上并不仅仅限于容灾备份，而是更大范围的企业数据复制，企业数据复制的作用包括灾备、审计、归档、共享访问等用途，据IDC统计，一个企业中的数据至少会存在7个副本，用于不同的目的。CDM的目标是让少量的副本发挥更多的作用，一个备份副本，同时可以作为审计库打开使用，也可以在开发测试中使用，在危机时刻还可以用于快速恢复。听起来很不错，于是国内也有部分厂商推出了类似的产品，不过这些产品良莠不齐，大部分只是把一些外部磁盘远程挂载到生产库上，使用rman copy命令把生产库的数据文件增量copy到远程磁盘上，当生产库出问题的时候，远程挂载这些磁盘，快速拉起系统。对于备份来说，这是有效的，不过如果产品存在BUG，很可能导致增量COPY的时候生产库出现问题。大家在选择与部署时一定要小心谨慎。