数据库容灾、复制解决方案全分析

Lee_Bill

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

cyr1974

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

xeme

存储是通过快照来记录状态，然后再进行复制进行备份的。
其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句

wzy25

最初由 xeme 发布
[B]存储是通过快照来记录状态，然后再进行复制进行备份的。
其实最好的方法应该是捕捉redo log file 的信息，将其翻译成sql语句 [/B]

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

herycom

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

irene_sh

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

samchj

看了大家的帖子，我也想说点东西，一直以来做的就是容灾和备份的事情。
目前的所谓的容灾可能包含两种方式：
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以后能做好，其他人不要轻易尝试。

dx6340

不知道能否把产品名字透露一下啊？
如果没有猜错应该是DSG的了？
DGS和shareplex的比较让市场来说话吧。

samchj

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

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

在效率上，对于处理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精确分析装载的软件要慎重使用，因为他的问题是很多的。

biti_rainy

楼上的你们产品是什么啊

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

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