数据库容灾、复制解决方案全分析(绝对精品)要点

数据库容灾、复制解决方案全分析（绝对精品）

目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案：

（1）基于存储层的容灾复制方案

这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。

目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。

（2）基于逻辑卷的容灾复制方案

这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。

我一直有一个困惑，存储级的复制，假如是同步的，能保证数据库所有文件一致吗？或者说是保证在异常发生的那一刻有足够的缓冲来保障？

也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？

上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案

我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧……

我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失，也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。

所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。

不知道我的理解对不对，也不知道是不是回答了你的问题，呵呵。欢迎指正！

应该说部分地回答了我的问题，呵呵

因为实际上存储设备的写入顺序和oracle 的进程的写入顺序肯定是不一样的，存储设备一定是做过重整的，那不管同步或者异步的拷贝都有可能存在问题的。

所以我一直对这个方案的可靠性不敢完全相信，这样一来，倒不如data guard 可靠了

因为很明显，存储设备拷贝过去的数据文件不一致是有很大的概率的

你的意思是说即使不考虑目标端，仅在源端的情况下，存储设备的写入顺序也是和Oracle不一致的？这应该是一个原因。我觉得还有一种可能性就是在忽略存储设备的这种情况下，在主系统当机，发生切换的时候，主系统存储上的数据文件也不一定能保证一致，就算目标系统保持了完全的同步，也一样不能保正目标端数据可可以启动。不太理解，为什么说存储设备的写入顺序会和oracle进程的写入顺序不一致阿

如果说仅在源端情况下，存储设备的写入顺序也是和Oracle进程不一致，那么不考虑异地冗灾，那么是不是意味着即使本地服务器crash，也无法启动存储上的数据文件？我也有这个疑问，以前一直觉得仅考虑主系统的情况下，存储设备的写入顺序应该是和数据库的写入顺序一致的，但我觉得biti_rainy的理解也是有道理的，存储设备毕竟和一般的磁盘不一样，很可能再写入的时候会作重新的组合，不过不知道具体的证据是什么啊？

按照这种理解，再写入的某一瞬间，数据库的写入顺序和存储的写入顺序可能是不一致的，但既然存储写入的结果跟oracle的写入结果肯定是一致的，那么我们可以把一个比较长的写入过程分成若干个时间段，在每个时间段的结尾，oracle和存储设备的写入结果都是完全一致的，那么这个时间段的大小是多少呢？

呵呵，说得我自己都快晕了，也不知道大家明白我的意思没有……

biti_rainy能不能给我们解释一下啊？或者论坛里有没有对存储设备比较了解的兄弟啊？

系统上通常不一致没关系是因为还有logfile 的存在，而日志文件通常是被写入了磁盘的，oracle本身是顺序写的，还不需要读，应该是被重整的几率比较小

还有存储设备上，比如掉电没关系，是因为存储设备都有足够的短时间供电能力使得cache 中的数据能被写入磁盘，这个如果不能保证那一掉电基本都要出问题的

但是在复制的那端，我就不清楚是怎么处理的，比如我要停掉复制，开始用起这数据来，或者说设备掉电了，这个时候是怎么处理的

在复制的那端，我感觉是没有经过特殊处理的，因为存储设备完全是物理上的同步，在你停掉复制的时候，他最多只能保证在停止复制或原系统掉电的这一刻所有文件在物理上是和原系统的存储是完全一致的，但他绝对不会去校验或保证oracle的数据文件在逻辑上是否一致，所以会造成复制端在停止复制后有很大几率不能正常启动。我

在客户那的情况就是在原系统正常运行的情况下，停止存储的复制，然后启动目标端数据库，但还是有1/3的几率无法启动，如果是在原系统发生故障或断电的情况下，估计就更不好说了。

我还是比较佩服那个客户的勇气，一个省级移动运营商的数据中心，数据库连归档都没有，一旦系统崩溃，至少要损失当天的数据，同时容灾端的数据库能不能起来还是个问题……

还好目前还没有出问题，要是出了问题，不知道他们会怎么办……

上次做存储设备的来公司，谈到这个问题的时候说：很多客户就是这么做的

我就说：很多人这么做的并不能说就没问题，因为很多人没有出现事故，是因为隐藏的问题没有机会暴露出来。我需要：

1：机制上的可靠保障，这个可能只有非常理解原理的人能回答

2：实际系统的测试，要经过在我们自己提供的数据场景下反复测试

通过这两点之后我们才敢放心使用

同意，确实很多人都是这么用的，也确实都很可能出现问题，所以我一直以为基于存储的数据库容灾方案是有问题的，但在有些环境中好像还只能这么做，例如我们的一个客户，也是一个省级的移动运营商，其数据库每天的日志量达到100G以上，在这种条件下，好像只有这种解决方案比较可行，其他的都会有一些问题，至少那些使用软件实现的逻辑复制方案是不行的，我感觉oracle自己的standby好像也负担不了吧？不过他们的数据库至少还是归档的，还有一点保证。呵呵。

从ORACLE的角度来衡量基于存储的容灾肯定是有问题的，不可能做到100%可用。

即使是ORACLE的DATA GUARD也不能保证100%没有数据丢失（当前日志组的数据）。

换个思路了，使用基于应用的同步方案吧。

（3）基于oracle redo log的逻辑复制方式

使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。先介绍一下第三方的软件产品吧……

目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品，但在产品的成熟程度和成功案例上跟国外还有一定的差距。

这类产品的原理基本相同，其工作过程可以分为以下几个流程：

使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制（主要在oracle9i环境中）。

这种技术的技术特点和优势主要有以下几点：

目标端数据库一直是一个可以访问的数据库；

能保证两端数据库的事务一致性；

因为使用oracle以外的进程进行捕捉，且其优先级低于oracle进程，所以对源系统数据库的性能影响很小；

基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；

因为这类软件复制的只是sql语句或事务，所以他可以完全支持异构环境的复制，硬件的型号，oracle的版本，操作系统的种类、版本等都没有要求。

这种方式还可以支持多种复制方式，比如数据集中、分发、对等复制、或者多层测的复制等。

由于传输的内容只是redolog 或archive log中的一部分，所以对网络资源的占用很小，可以实现不同城市之间的远程复制。

基于redolog的逻辑复制产品有很多的优势，但跟上面提到过的其他方案比较起来，也有一些缺点：

数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；

实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；

复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。

不过目前这类产品的发展很快，上面的这些问题，在大部分产品的最新版本中都有很大的改进。

您说的备中心1/3机会不可用，是同步复制还是异步复制的情况？

是指同步复制的情况。

这个数字我不敢保证它的准确性，因为我没有做过实际的实验来验证，但从我在客户那里看到的实际情况来说，基本属实。

您能告诉我你的客户用的那一家的产品吗？

不管是同步环是异步只要不是在数据库里面做宕机时总应该有数据不一致的情况吧因为数据库写文件是由操作系统来最终完成的，而操作系统本身又有cache，在通过逻辑复制把数据异步或同步复制到其他存储设备上，中间无论哪个环节有问题，远程存储设备的数据都不能同现有数据保持一致，所以我认为biti的怀疑是很有道理的。到10g oracle可以使用assm，直接同存储设备对话，这样是否能够好一些，不太确定

存储是通过快照来记录状态，然后再进行复制进行备份的。

其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句

这就是oracle stream 和quest shareplex实现的功能

利用oracle 9i的高级复制，加上第三方的管理工具就可以了

我对oracle 的高级复制研究较多，觉得这是最好的方法，能够完全保证数据的一致性。但管理起来比较麻烦，需要利用第三方的管理工具就可以了。我用的是深圳华尔东城公司的管理工具，能够自动进行简单故障处理，目前设置的10分钟增量同步，最大表有4000多万条记录，目前还只同步了一部分表，数据量达到了50G。

容灾实际例子，不知道是不是有帮助

曾经评估了几个这方面的方案，一是利用存储本身提供的功能，在两端距离比较远（几百几千公里）的时候，只能用异步的方式，同步的话对网络的带宽要求很高，除非两端能够用光纤直接连接。异步的方式根据厂商的解释是这样的，远端存储上的写是无序的，不会根据生产端的次序写入，对用户来说是透明的，没有办法干预，也就是说对oracle来说是不同步的，如果没有人为的干预进行一次同步的话，数据库也没有办法启动。但是如果要同步的话就会对生产数据库产生影响，处于suspend状态。至于停电等各种极端情况我们在同城同步做过测试，没有问题，存储能够保证数据的一致和可用。异地异步没有测试过，不知有哪位兄弟做过这个试验，能告诉结果。

看了大家的帖子，我也想说点东西，一直以来做的就是容灾和备份的事情。

目前的所谓的容灾可能包含两种方式：

1.真正的容灾，目的就是为了防止在灾难发生的时候能减少下线时间。这个过程没有一个能做到零下线的。

2.”假“容灾，即所谓的ods，数据复制。出来的数据不单单能达到容灾的目的，而且目的端数据可以实时被使用。

第一种方式可能是鸡肋，因为花那么大的投资使用当前的硬件容灾方式去达到一个可能领导在任期间都不能发生的灾难，实在让人觉得不太值得，除非厂商给了这个领导很大一笔钱，不过当前许多电信行业都说要建容灾中心。

第二种方式确实是一种很诱人的方式，也是我现在做的产品。这种方式主要采用两种方式实现：

a.使用我们现在的同步工作实现首次同步（逻辑上的导出，也是一种鬼才写出了这个东西，当然他是我们老总），然后直接转入监控online redolog进行日志监控分析转化，然后传送到目标端装载。

b.使用类似于bcv/ca/flashcopy这些快照类软件在磁盘存储级做成首次同步，然后使用我现在的产品做日志监控，加载到目的端。

这个产品作了1年多，应该说比quest的shareplex强大的多了，但是我并非在此宣传产品，所以我要说的是公平话。

通过oracle内部方式去达到实时同步可能本身就是一个错误，类似于oracle本身的advance replication以及data guard也是日志分析方式的，他的主要缺点在于效率上存在问题，就是装载数据量很大的时候，根本不能应付，这也是shareplex的毛病。因此我现在的产品在这个上面是克服了这些缺点，效率绝对的高。我和oracle的stream，quest的shareplex，以及非用于容灾方式的data guard等对比过，大家互有长短。

关键就是，采用基于这种精确分析的复制方式，如何保证数据是完全准确的：

1.没有有效的检验方式，检查数据是否一致，有类似于select minus select的方式，但是对于超过100M的表，除非你有足够的耐心，我经常见到表最大是92G，没有分区，很变态。

2.就算你知道了丢失数据，如何把这个数据补回来。现在的类似于我们的软件，都采用了rowidmap的方式去做精确定位，所以如果丢失了，你如何补回来。我知道quest 是重新同步，我们是把整个表重新同步，因为我们的逻辑到处快。

这些都是基于oracle精确复制需要解决的最大的问题。

呵呵，当然了关于这个里面处理很多oracle的特殊操作的时候还有很多需要做的事情，quest做了8年多了吧，到5年后才支持chained row，不能不说这是一个悲剧。还有许多的操作类型怎么办：ddl

,truncate,rollback savepoint,nologging等等，当然日志了没有的时候，你如何做。我个人的观点，基于oracle的精确分析复制方式，除了oracle以后能做好，其他人不要轻易尝试。

不知道能否把产品名字透露一下啊？

如果没有猜错应该是DSG的了？

DGS和shareplex的比较让市场来说话吧。

每个人都会说自己的产品好，但是希望在itpub这个地方

还是要说出一些更多技术上的东西。

samchj说“此我现在的产品在这个上面是克服了这些缺点，效率绝对的高”，并且也提到你们的产品也是通过监控redo的变化，提取SQL，那么为什么你们的效率会绝对的高？

希望能从机制上说明一下这个问题。

首先我澄清一下，我没有宣传产品的意思。

我必须让事实说话，而不是市场说话，市场存在很多人为因素。

在效率上，对于处理chained row这种在数据库中经常出现的东西，不能采用sql statment执行的方法。而shareplex是使用的这种方法。曾经我在测试的时候就对比过这个东西。因为chained row 包括migrate row &chain row 两种。而mr在oracle中只有一个rowid，而cr却不止。因此如果你采用的是rowmap方式精确定位两边的表，那么在处理chain row的时候，除非你能很好的处理，否则最简单和准确的方式就是直接在源端找到这个行，然后通过sql statment的方式装到目的端。这样在速度上是很慢的。

效率的提高主要从分析速度和装载速度上讲的。

我不知道shareplex日志分析是如何进行的，这当然也是这类型软件的kernel了，这是算法问题，我想起基本原理和logminer都差不多，在算法上优化分析速度是很重要的。

在装载问题上，其实shareplex也曾经使用过direct path的装载方式，但是因为direct path本身就存在很多bug，因此干脆就放弃了这种方式，因为据我所接触的通过direct path装载的bug就很多，例如索引不能使用等。所以只能通过conventional path来装载。这就是规规矩矩的转换成sql statment，然后交给oracle通过解释成binary 后在装载

了，这是很浪费时间的，而且对于qmi（基本由creat table as select引起的oracle 特殊插入处理）来说，这是很不合理的，因此在这里应该做些事情，当然细节不便于说。

另外对于首次同步的导出和装载，现在的oracle10g也许就是使用的这种方式了，你可以看看oracle10g的export为什么如此快。

我还是说，不论是否市场怎么样，使用基于oracle精确分析装载的软件要慎重使用，因为他的问题是很多的。

楼上的你们产品是什么啊

关于这类产品的一些特别情况的处理我一直很关心

另：10G 使用的*expdp* 和*impdp* 应该是由DUL + SQLLDR direct 思想的结合吧

我们现在用的是Oracle 9i ，想用复制软件VERITAS Storage Replicator 3.0使两台服务器上的数据库同步，应该复制Oracle下的那些数据文件，表空间？还有复制后应该怎么做？

服务器硬件说明：

两台服务器为了节约成本，没有使用双机热备，没用磁盘阵列，每台服务器用4块SCSI 硬盘做成Raid 5，两台服务器操作系统，数据库安装路径，设置都一致，有没有解决办法啊?

使用SQL Server 2000数据库把数据文件复制到另外一台服务器，数据库可以实现同步，但是Oracle 9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。对于samchj 一直说：然后通过sql statment的方式装到目的端。这样在速度上是很慢的，然后交给oracle通过解释成binary 后在装载了，这是很浪费时间的？

－－－－－－－－－－－－－－－－－－－－－－－－

能否举出实际的例子？拿出具体的数据来说话，你所谓的慢是什么程度？

澄清一下，shareplex 不是使用你所谓的direct path 方式。

dx6340老兄，我不是在宣传产品，我再澄清一次。如果有人对我现在做的产品感兴趣，可以给我写邮件，但是我们只谈技术，不谈市场，但是在itpub上或者任何其它场合，我不会说我的产品是如何的好，虽然我的和shareplex做的对比测试很多。他们各有各的优缺点。

shareplex确实不使用direct path装载，这个我也说过“其实shareplex也曾经使用过direct path的装载方式”，我是说曾经，从研发上讲。你可以用shareplex或者oracle的data guard等做实验，当大数据量的时候，你可以看看他是否能分析过来和装载过来，延迟时间多少。一秒钟能支持的update有多少，insert有多少，如果做ddl是否需要先停止复制。这些还只是很基本的处理。logminer尚且对日志的分析很慢（不过可以用多进程来弥补，如果你有很多的系统资源）。

wbo兄弟的“Oracle9i把一台服务器上的表空间复制到另一台服务器后数据库不用能。”，我的理解是，如果你使用基于存储级的复制产品，你同步的应该是整个设置的卷或者卷组，他没有什么oracle的逻辑结构复制方法吧，要么就是把这个表空间创建在一个卷组上，然后设定复制这个卷组。如果你硬是要复制一个表空间过去，我觉得你应该先通过oracle的TRANSPORT_TABLESPACE来，但是好像很没有必要。使用存储级的复制不能实时打开，打开必须断开。

对于基于复制中的特殊方式处理，主要有这些：

1.采用何种装载方式

2.如何准确快速执行delete和update，因为这两个操作需要rowid，有人采用在数据库本身创建很多的表来维护rowid。

3.对chain row的处理

4.对各种ddl的处理(truncate,create,drop,alter)

5.对于未提交的事务的处理

等等,因为我确实还没有来总结这些资料,这里先列各提纲,我一个一个来总结.

1.装载方式:

在oracle中装载数据库不外乎两种方式:direct path和conventinal path装载,其

中类似direct path装载就是例如sqlload等工具使用的装载方式,因为它省去了sql 语句的编译\绑定(kk/kx),直接转换成绑定后的格式对extent进行操作.而conventinal path装载方式确实普通的装载方式,即类似于标准的sql语句的装载.后者比前者在同等条件下要慢5倍.当然两种方式的装载速度还和表本身的结构和大小有关.我测试的速度最大有12倍的差距.

在装载上,你还要考虑更多内容,你不能单单调用oracle sqlloader,因为在oracle中有很多的oracle特殊处理的东西,例如:qmi,qmd.oracle在这里对于这些操作有在redo中有特殊的标志,如果你采用create table as select来创建表,你会觉得它比现创建然后用sql语句插入要快的多,在日志中他也只有很少的记录.因此,在处理这些的时候,你要采用特殊的算法,所以调用oracle的现成工具是不理想的,曾经在oracle7之前oracle并没有将upi (好像是这个名字)封掉,但是在oracle8i后,oracle不再开放该接口,因此很多的程序员对于这个层面了解很少.当然现在你很难找到.oci只是封装后更高级的接口而已.

因此装载程序的设计,对于基于oracle精确分析方式的复制有很大的决定作用,这里面还有更多的处理,我也不能一一列出了.

呵呵，楼上的这个工具就是你自己开发的吗？

如果你老板能找到一个肯研究OCI --> UPI --->OPI 的手下并一直坚持对oracle 的研究，在国内简直是太不容易了。

没其他意思,如果不是你开发的，除了对这一部分外，对oracle的整体问题你有过研究吗？

呵呵，我不知道oracle的整体问题是什么意思，oracle太大了，我涉及的有关于oracle 的备份恢复（包括非归档物理热备份，各种恢复方式，以及你们都已经在讨论的热备到底在做什么，那都是我很早前学的，反正备份的东西夸大点就是知道原理的东西多些，不过不敢在任何地方卖弄，因为技术这个东西很难说，嘻嘻）。

搞我们这个容灾产品也有很久了，基本涉及的有联机日志分析，各种特殊操作的原理等等，不能详细罗列，但是在装载上说实话，我只是知道经过哪些层次，并没有开发，而是帮助开发作单元测试，所以知道比较详细些而已，知道对于我上面写的东西如何处理。同时对比过诸如：shareplex，stream，data guard等软件产品性能和基本的一些原理，也和存储级复制软件结合，做过组合测试而已。

对于oracle的调优工作，我还是不如大家的，不过我看eygle老兄的东西都很接近我学的东西，因为确实我曾经站在了“巨人”的肩膀上，嘻嘻，还要向大家多学习，学习。

要说深入oracle，也只是在看大家写的东西的同时，自己总结在这些年学习的东西，和大家分享，因为我觉得，我在网络上学了些，当然我也想将我学到的东西给大家分享，呵呵。

明天继续对于这种产品存在的各种瓶颈作分析，也希望大家指正，我申明一点，我不做产品宣传，只是在我都测试过的基础上总结，绝不胡说

其实也没什么,整体方面是说oracle的文件、内存、进程等比较全面的东西，

对于oracle internal 比较有兴趣一些，如oracle 内存、文件管理、进程间通信

宏观方面备份恢复、tuning、体系结构，这些都是在前面internal基础上的具体应用，了解了internal后在管理方面就不局限于固定的模式了。

比如喜欢这样的探讨：

呵呵，当然，我关注的也是这些。

我努力想成为一个像我们老板一样的高手，他能将这些东西转换成程序，呵呵。

但是我不能把他拉到itpub上来，否则，中国的oracle研究者有福了。不过我愿意将我在他那里学的东西共享给大家，和大家一起研究。也请多指教。

你们老板……当初是从哪里学来的呢

因为如果原来不是oracle的人的话，我仅仅知道国外这样的人有一些，国内的同时精通oracle+os + 开发的人，很罕见的。我只是听闻国内有oracle的人出去做这类产品去了，但具体名字不清楚，不知道是不是你们老板。

这个如果基于存储的复制方式是同步的,这是可以保证的.因为同步复制是复制IO,而且是主机端写IO的顺序技术复制的顺序,主要分成以下四步:主机端一个IO下来,存储复制到远端,然后远端完成IO,最后返回通知主机IO完成. 但是存储不保证数据库在此时逻辑上是一致的,这是靠数据库本身的机制来完成的. 即此时源端数据库崩溃,如果可以通过数据库相应恢复手段来恢复的话,远端复制的存储也可以.

但如果是异步方式的话,问题就比较麻烦. 异步与同步的区别就是,异步主机IO下来后不需要等远端存储IO完成和确认,直接返回主机端IO完成. 这些IO暂时存放在源端存储缓存里,等累计到一定程度或满足给顶条件时,在传送到远端. 此时如何保证传递的IO顺序从而保证逻辑一致,就与具体的产品有比较大的关系了. 有的产品没有保证机制,直接用存放的顺序发送, 但在实际传送过程中没有保证,如由于线路等原因造成部分传送等. 有比较好的旧有时间戳和顺序号,而且还有逻辑分组,即主机端IO下来的时候是事务相关和逻辑分组的. 存储就将这一组IO逻辑分组,按写下的顺序标号, 这样在异步传送到远端后就可以根据逻辑分组和IO标号来完成IO. 类似具有事务的性质.

同步如果是从主机下来的IO直接复制，这样频繁的小IO将造成网络的大量问题，这对网络的要求太高了。以前都是听人说同步是从存储的cache 来的，拷贝的时候封锁cache不允许写……

我觉得这个和同步I/O和异步I/O没有关系，对于存储级的复制，他们都有一个队列来保证I/O的次序，这是类似于ca/emc等厂商的这些存储级（varitas文件系统级）复制的一个共同点。至少我知道veritas声称的原理是这样的。

如果不能保证I/O的次序，存储级复制没有任何意义。而且像ca这样的软件，他并不是实时改变多少就穿多少，我觉得他记录在磁盘头的tab应该隔多少时间加一次锁，然后新的插入写cache，所以如果这个时间源端off的话，cache中的数据应该是丢失的（磁盘坏）。

软件级的复制也一样，你总有一个队列来处理ops/rac的事务顺序，这个队列有放在磁盘上用文件来排队的，也有直接在内存中排队的，这些也是关键的东西。当然像软件复制这样的软件可以通过重新分析日志的方式来弥补，如果磁盘没有坏的话。

同步绝对就是那样，每个在SOURCE端写入的东西必须被远端的存储设备写入成功（不一定是写入磁盘）才返回主机写入成功，基本可以认为就是一个距离很远的RAID1。一致性的问题不用担心，但是带宽要求等等都是很高的。

异步的方法，在之前很多是不能保证一致的，呵呵。最近据说多了很多能保证一致的方法，就知道HDS会吧所有写记录到本地一个日志卷，EMC和IBM的方法还没有弄的很清楚。

看看我们的实际应用

现在介绍我们数据库同步的成功案例，你们提到的问题都可以解决。

现在我们的数据同步已经投入了实际运行，采用逐步增加表的方式。目前已经同步了149个表，其中包括详单表，统计基表等。最大的6000多万记录，有16个超过1000万记录，采用10分钟异步复制。主要有以下特点：

1、关键业务数据（排出了很多垃圾数据），数据量最小

2、对生产机影响较小，目前一般只用到300M 空间

3、目标端数据不可以修改，完全保证数据一致

4、初始同步快捷、方便，不需要停止生产系统应用。影响小，只相当如一个select。

5、管理方便、灵活：能够看到各表上次同步时间；上次同步后又有多少条新数据；上次各表同步耗费多长时间等。

目前每天进行一次count(*) 检查，没有发现有问题。

我们一前也试用过dsj和shareplex的产品，从名气上来说，应该还不错。具体不是我亲自试用的，但最后没有能够成功，我想与我们的系统复杂、数据库本身不是很稳定、要求太高有关。

1、这是一个24小时运行的系统，停止应用程序来进行初始同步比较麻烦。

2、需要在每天早晨从同步的数据中产生关键的数据和报表，要求不能耽误。

3、要求管理维护简单、灵活：要求运行稳定，同步中断后能够简单快速处理完。

现在我们用的oracle机制，加上第三方数据同步管理软件，只用了1个晚上就将主体数据同步好，一周就正式投入使用。然后逐步完善增加同步的表，目前已经同步了149张表，还对同步数据进行了分区处理等优化，从目前的近一个月的情况来看效果理想。经过一年半还多的时间试用了2家产品没有能够成功，用一周时间就解决了问题（主要报表实际上第二天就正式使用了），心里是多么的欣慰、兴奋和富有成就感。

所以写了这么多东西。

就是用了ORACLE物化视图技术+一个图形界面配置，还以为是啥东东哦。

还有谁为建立报表机和容灾的数据同步而烦恼吗？

oracle的功能确实很强大，这需要大家一起去挖掘，才会有基于oracle的更多更好的应用软件产生。

samchj兄，你是DSG的吧？海龟从ORACLE,IBM出来，而且专攻容灾的公司，我想不出第二家。你们的技术很牛，对底层很清楚，但让人担心对ORACLE后续版本的支持。虽然所宣称的产品功能实现很吸引人，在测试中有不少问题，亟待完善。VP忙着改BUG，应该是没有什么时间来这灌水。

关于BITI担心的存储同步问题，楼上的已经解释很清楚了。之所以存储厂商要求主节点、容灾节点更换成他们的存储设备，就是要解决I/O,CACHE的问题，从而保证同步端能够做到完全镜像。

容灾端只有停掉同步，才能打开数据库，然后下一次再重做同步。而且他们还提供SNAPSHOT的功能，建立一个快照数据库，对于一个大数据库，需要的存储很可观。

我个人认为，存储厂商的最大优势在于维护量少，有保障。DATA GUARD配置灵活，不依赖于底层，但需要人为监控。

声明：我们这用的不是DATA GUARD

是一个第三方软件，目前报表机同步底层用的是实例化视图。

如果建立应用级的容灾，数据需要实时同步，估计需要用到同步复制技术了。目前还没有下决心做，担心性能问题。目前有过1个表的初步测试，还没有进行大量表的测试。

对你的ppt提几个疑问：

1。传统同步软件方案为10年前的技术，比较落后。

这个恐怕有些武断，相反对于数据库的复制我个人更看好如Quest的shareplex等产品。同样dataguard也使用类似技术，绝对不是如你所言是10年前的落后技术。

2。传统同步软件方案，因其本身的缺陷，导致需要大量复杂的机制和操作来保证数据的一致，实施成本大。

复杂的机制不是最终客户需要考虑的，相反这些软件的实施成本是相应较小的（当然如果你的成本是指money的话，那自然是比物化视图高，不过仍然可以选用DG），说起复杂的机制，即使是你使用的物化视图，也仍然有大量内部的控制是较复杂的，不过这些不需要实施者去考虑而已。

3。采用硬件存储快照的方式，同步方式不灵活，将生产系统上所有的数据全部同步。（经过长时间运行和维护的生产系统往往大量的临时表和大量的垃圾数据，这些实际上是不需要同步的。

通常基于存储的复制提供了卷一级的管理，完全可以通过配置不同的数据文件在不同的卷上来达到复制关键数据的目的。

4。采用硬件存储快照的方式，耗费大量的存储设备，成本巨大。

就我所知，至少veritas的vvr不需要太多额外的存储。

5。华尔东城公司采用的独特方案，采用oracle的各种技术相结合，结合本公司独特的同步参数设置。通过本公司软件控制进行同步的管理。

其实你这个ppt真是说的很含糊，用于单纯的sales宣传恐怕还可以，如果是用于技术交流实在是有些不痛不痒。

6。华尔东城产品重要的益处，保证容灾数据完全一致，报表数据与10分钟前一致。既然有10分钟的差距，为何仍然说容灾数据完全一致？如果说你们使用了物化视图的

方案，那么就不可能在一个刷新期内（你们这儿的10分钟？）保证数据不丢失。除非还有业务log的分析软件作后备。

7。华尔东城产品重要的益处，对主机性能影响小。

其实物化视图的刷新对于主机并不是很小的影响，如果10分钟之内需要刷新大量的数据，可以明显的看到CPU的波峰，特别是oracle本身对于mvlog的处理还是有些问题的，所以不确定你们是否真的作过跟其它专业同步软件的主机性能影响的比较。

8。本公司得益于oracle新技术的推出，加上本公司的努力，终于能够为数据同步提供完美的方案，这也是我们值得骄傲的一件事情。

不否认你们确实作出了一个比较完备的同步解决方案，但是希望能够本着技术交流的想法在itpub讨论问题，而不是作单纯的商业宣传。我想很多人都希望知道你所指的oracle新技术是什么？不应该说就是物化视图吧。