oracle数据库容灾、复制解决方案全分析(编辑修改稿)

oracle数据库容灾、复制解决方案全分析(编辑修改稿)内容摘要：

我和 oracle 的stream， quest 的 shareplex，以及非用于容灾方式的 data guard 等对比过，大家互有长短。 关键就是，采用基于这种精确分析的复制方式，如何保证数据是完全准确的： ，检查数据是否一致，有类似于 select minus select 的方式，但是对于超过 100M 的表，除非你有足够的耐心，我经常见到表最大是 92G，没有分区，很变态。 ，如何把这个数据补回来。 现在的类似于我们的软件，都采用了 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 amp。 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 使两台服务器上的数据库同步，应该复制 Oracle 下的那些数据文件，表空间。 还有复制后应该怎么做。 服务器硬件说明： 两台服务器为了节约成本，没有使用双机热 备，没用磁盘阵列，每台服务器用 4 块 SCSI硬盘做成 Raid 5，两台服务器操作系统，数据库安装路径，设置都一致，有没有解决办法啊 ? 使用 SQL Server 2020 数据库把数据文件复制到另外一台服务器，数据库可以实现同步，但是 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 兄弟的 “Oracle 9i 把一台服务器上的表空间复制到另一台服务器后数据库不用能。 ”，我的理解是，如果你使用基于存储级的复制产品，你同步的应该是整个设置的卷或者卷组，他没有什么 oracle 的逻辑结构复制方法吧，要么就是把这个表空间创建在一个卷组上，然后设定复制这个卷组。 如果你硬是要复制一个表空间过去，我觉得你应该先通过 oracle 的 TRANSPORT_TABLESPACE 来，但是好像很没有必要。 使用存储级的复制不能实时打开，打开必须断开。