从数据块结构看目前主流容灾技术

Write by 白鳝-http://www.oraclefans.cn/forum/showtopic.jsp?rootid=42158&CPages=1
之前做过测试打算用HP的snapshot做逻辑容灾,大致思路如下：
对于生产A中的VG，利用snapshot技术间隔一小时做快照，共有3-5套VG，轮流去做快照，也就是说A上可以挂在3-5套生产中数据卷组快照。
当出现逻辑错误，比如生产A在15:30Truncate了一张表。那么，现在已经是16:10了，那我可以再灾备B上挂起15点的快照，然后把生产A的归档LOG传递到灾备B,
数据库启动在mount状态下，然后进行基于时间点或者取消的不完全恢复，最后通过resetlogs 打开数据库。
这样的方式其实是很好的，但是没想到hp的snapshot做快照的粒度不够精细，最后不完全恢复的时候打开数据库，总是存在系统表空间文件不一致的情况。
这个问题可以通过运行一个脚本来解决：
spool scandatafile.sql
set serveroutput on
declare
  scn number(12) := 0;
  scnmax number(12) := 0;
begin
  for f in (select * from v$datafile) loop
    scn := dbms_backup_restore.scandatafile(f.file#);
    dbms_output.put_line('File ' || f.file# ||' absolute fuzzy scn = ' || scn);
    if scn > scnmax then scnmax := scn; end if;
  end loop;
  dbms_output.put_line('Minimum PITR SCN = ' || scnmax);
end;
/
此脚本在有8个32G的裸设备文件的时候需要运行5分钟，当我最后把数据文件加到17个的时候，运行的时间基本是成比例增加的。鉴于此，也联系到oracle的人，尝试寻求dbms_backup_restore.scandatafile(f.file#);在扫描的时候更新文件头部信息，考虑能否知道内部的实际动作，然后采用并行的方式，未果。
发现老白写了相关的一篇文章,特转载于此.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
谈到容灾平台，很多DBA总是觉得这离自己很远，也许根本看不到容灾系统的启用。有一次在四川碰到几个朋友，谈起现在的容灾平台，我认为真正能启用的恐怕不到一半，而其中一位以前在某省邮储从事容灾工作的朋友则表示难以置信，他觉得当年自己开发容灾系统时是很认真的，而且有专人管理，定期演练时必须确保能够立马切换。也许我碰到的客户都不是金融行业的，容灾建设比较马虎吧。
正巧此时一个金融行业的客户打来求助电话，他们接到上级部门的通知，要进行容灾演练，而在切换容灾系统时，却发现系统中一套10g版本的Oracle数据库无法启动。
后来问题解决了，其实很简单，他们的容灾环境采用的是IBM的SVC复制，但是只复制了数据库相关的文件，并未同步操作系统的系统目录中的文件，而且host文件的配置也是错误的，所以才导致数据库无法启动。这个问题虽然不大，但却暴露出另一个问题，就是容灾平台疏于管理，当主生产环境变更时，没能及时变更容灾环境。在这些年的工作中，老白亲自经历过三次容灾切换，其中两次成功，一次失败。成功的两次都是切换到本地容灾系统，而失败的那一次则是切换到远程容灾系统。
先说说成功的那两次吧，当时客户要为系统添加RAC第三节点，由于存储容量不足，无法满足第三节点UNDO表空间和归档目录的需求，因此决定扩充一个由16块硬盘组成的扩展柜。由于集成商经验不足，新扩展的盘柜和磁盘的微码与原系统不兼容，扩容工作很不顺利。原定于周五晚上添加RAC节点，周四必须完成磁盘扩容工作，但是从周三就开始的盘阵扩容进行了一天半还是毫无进展。于是IBM的售后服务人员也加入了此工作，经过诊断，他们建议现场插拔一下磁盘，在反复了几次后，磁盘突然整个锁死，系统无法正常工作了。而这时正好是下午5点多，系统业务最高峰的时段。
经过我和客户技术主管的讨论，我们决定马上切换到容灾系统。当时此系统有两套容灾系统，本地容灾采用DATAGUARD技术，远程容灾采用类DATAGUARD技术将归档日志压缩后传输到远程进行注册和应用。远程容灾系统在离故障点100多公里以外的城市，配备了两台IBM P561服务器，而本地容灾系统只是利用剩余设备搭建的一个备份平台，其目的并不是为了容灾，而是为了减轻备份对生产系统的负载，它只包含一台IBM P561服务器，且仅配备了48G的内存，此配置与生产环境两台配备了72G内存的P570系统相比，处理能力明显不足。按照常理，在这样的情况下，切换到异地容灾系统是比较合理的，但是经过仔细分析，当时并不具备这样的条件，因为只有主生产系统在异地建立了容灾系统，而其余十多个外围系统并未建立相应的异地容灾系统。一旦将主生产系统切换，那么就需要更改上千个配置项才能够完成全业务的切换，而这项工作并无现成的预案和操作脚本，仅凭人工操作，很难保证系统正常切换。另外还有一个更大的问题，在远程容灾机房中，仅配备了几个初级的系统管理人员，并未配备专职DBA等维护人员，一旦进行切换，大家只能在远程操作系统，很难确保切换过程不出问题。
如果切换到本地容灾系统，只需要将DATAGUARD服务器的IP改为生产环境的IP，然后激活DATAGUARD即可完成，而且维护人员还可以在本地进行操作。不过最大的问题是本地的硬件配置明显不足以支撑生产环境50%的业务。于是我建议将生产环境上的部分内存插到容灾系统的服务器上。这个主意似乎很不错，但是由于生产环境采用的是P570服务器，而本地容灾系统采用的是P561服务器，大部分从P570上拔下的内存条并不能在P561上使用。于是只能又在备件库房凑了凑，才凑够了42G内存，将容灾服务器的内存扩充到了90G。在随后重启容灾服务器的过程中，又碰到了网卡不能自动激活的问题，总之经过一系列的处理，终于在一个半小时后恢复了系统的运行。虽然本次切换最终成功了，不过由于业务高峰期系统停止了近100分钟，大量业务被积压，并影响了货物通关，最终导致了惊人的损失。
在本次事故中，投入大量资金的异地容灾系统并未发挥应有的作用，反而是不在规划中的DBA的无心之作解救了这次危机。这个案例也暴露出了此容灾平台建设中的问题，这些问题其实是普遍存在的。
第二个案例差不多是10年前的事情了，这个客户采用的容灾技术和第一个案例不同，是采用存储级复制技术的，容灾平台配备了70%的处理能力。那次老白正好在客户现场进行另外一套系统的优化。由于生产系统的存储突然掉电，大量的数据文件损坏了。当时客户还很淡定，因为他们投入巨资建设了先进的容灾系统，而且这套容灾系统在几个月前还做过切换演练。但是容灾系统启动时，其中的一台数据库服务器启动不了，从错误信息来看，是由ORA-704和ORA-600错误引起的。当值DBA忙碌了几个小时还是没办法解决问题，突然想到这边还有一个做优化的DBA，于是就请我帮他解决。现在看来，那个问题其实并不难，主要是由于UNDO表空间存在坏块才导致数据库无法正常启动，通过_offline_rollback_segments和_allow_resetlogs_corruption参数，再辅以BBED，强制打开数据库就有可能解决问题，不过那时老白的技术还比较差，整整折腾了一天也没能解决。由于客户建设了容灾系统，就没有再建设备份系统，因此这个系统没有可用的备份集，最终老白只能祭出dul这个法宝，导出了数据并重建了整个数据库。虽然最终大多数数据被恢复了，不过整个业务却中断了5天之久。
和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字节，而Oracle的数据块大小是8千字节，也就是说，一个Oracle数据块包含了若干个磁盘块。从Oracle数据块的定义上来看，虽然Oracle的数据块分配的磁盘空间是连续的，但由于底层存储条带技术，系统不能确保Oracle数据块在磁盘上是连续分布的，甚至一个Oracle数据块有可能被存储在多个磁盘中。由于Oracle数据块和操作系统磁盘块之间的不同，就产生了一种可能性，一个Oracle数据块被操作系统分成了多个I/O写盘，这些I/O之间的时间点是不同的，因此在某个瞬间，远程容灾系统上数据中可能包含了一个数据块的某个部分的变更，但是缺少了其他部分的变更，这就导致该数据块中的各个组成部分是不一致的。通过块头和块尾以及checksum的比较，就能发现数据块处于不一致状态。这种情况的表象就是Oracle读到了坏块，也就是我们常说的块断裂现象。这就是为什么使用存储异步复制技术的容灾系统，在数据库打开后经常会发现坏块的原因。如果坏块正好出现在UNDO表空间中，或者出现在一些关键的系统数据字典表中，那么在打开这个数据库时就可能会出现问题。
对于一般的系统，块断裂发生的几率并不是太高，但是对于数据变更十分频繁的7×24系统来说，出现的几率会大得多。之所以那个客户在容灾演练时没有发现问题，主要是因为客户在此期间通常会停掉业务，这样数据库就处于相对的静态，出现问题的几率很小，而实际生产系统故障需要切换时往往是业务高峰，出现块断裂的可能性几乎是100%。
这类容灾技术有很多，主要的方案提供厂商包括EMC、赛门铁克（赛门铁克采用卷复制技术）、飞康、HP、IBM等。原厂的工程师总会宣称他们的算法是经过严格认证的，能够确保容灾系统上的数据完全复制自生产系统上某一瞬间的数据，并且在时间点上肯定是一致的，因此不存在不可用的问题。这个说法看似很有道理，不过仔细考虑一下，好像还是存在漏洞。时间上的一致性，就能确保数据库的一致性吗？要解决这个问题，就需要认真研究数据库一致性的条件。我们假定有一个一致性的存储snap，在这个snap上，没有任何一个数据块是断裂的，那么我们认为这个snap是一致性的，反之这个snap是非一致性的，在这种情况下打开数据库，可能就会出现坏块。如果坏块出现在SYSTEM表空间或者UNDO表空间中，数据库甚至可能无法打开。即使某个snap是一致的，数据库就一定能打开吗？在进行数据库介质恢复时，如果在某个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 Snapshot Technologies [ID 604683.1]中，Oracle提出了一个不需要BEGIN BACKUP/END BACKUP也能实现一致性复制的设想。这篇文章往往会成为很多存储厂商认为自己的存储产品是能够不实用BEGIN/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.
不过如果你继续阅读下面的前提条件：
Third Party Snapshot Prerequisites
The third party vendor needs to guarantee and held accountable that their snapshots conform to all the following requirements:
1.Integrated with Oracle's recommended restore and recovery operations above
2.Database crash consistent at the point of the snapshot 
3.Write ordering is preserved for each file within a snapshot
你会发现这种场景对snap的要求十分苛刻。第一点和第三点比较容易实现，目前EMC的SRDF，HDS等产品都支持根据写顺序的数据复制。而第二点是十分苛刻的，是数据库在snap点上一致性宕掉。这种情况在真正的容灾环境下，有可能总是能幸运的碰到吗？很多客户在测试类似的容灾平台的时候，总是通过突然杀掉生产库的实例来验证容灾是否起效，这么测试，肯定是百分百的成功，因为这种情况，对于容灾库而言，就像是数据库实例宕掉后重启一样。如果你尝试在生产库直接关掉存储（包括备用电池），这种情况下，你的容灾库是否还能很幸运的启动呢？我想如果这样，你真的十分幸运。
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本地容灾系统，远程使用基于存储复制技术的远程容灾系统，也许是不错的选择。