请教一个关于shareplex的问题

晶晶小妹

很多人都对我说，使用这种挖日志的方式，除了Oracle，没有人可以百分百的保证目标库与源库一致性。

晶晶小妹

“把原系统和目标系统的roid做一个对应的rowidmap，使用rowid来定位记录”

只要算法设计合理，这种方式应该是最好的方式。

lc7888

这个帖子还在啊？
回答一下：
1、关于数据一致，日志挖掘本来就是对日志中的数据进行了筛选，SharePlex需要保证的是应用数据的一致，而不是整个数据库的一致。所以这种说法可以说是对的。
2、使用何种方式进行数据的加载并没有那种方式能说是最好的，只能说各有优缺点吧。

晶晶小妹

说法是对的，但很人都告诉我，由于Oracle没有公布日志的格式，而且Oracle日志的格式中，有很多非常怪异的内容，因此这种挖掘日志的模式，不是太可靠。

eagle_fan

oracle自己的logical standby也是有一堆的限制和一些莫名其妙的bug
这种复制的产品问题都不少

也许11g active standby才是王道，不知道license价格如何

lc7888

首先坦白一下，我是Quest中国公司的人，所以了解得会多一些。
Quest是从oracle7开始用这种方式作oracle数据复制的，按照我们研发部门的说法，Oracle新版本推出后，会给我们研发部门有一个专门的培训，所以我们可以在最短的时间内实现对oracle最新版本的支持。至于日至中的那些具体数据格式，即使很奇怪，也会有规律可循，并不是没办法研究的。
从oracle7 到oracle11g，Quest都可以在Oracle最新版本发布之后一年内推出支持的版本，所以目前为止，我到对这个问题不太担心，当然，如果担心，也轮不到我，呵呵。

PS:厂家的解释，难免有吹牛的嫌疑，所以仅供大家参考。

fxyj2008

11g 的 ACTIVE standby 确实不错的 ， 但目前 还是有不少bug  ，相信oracle 在接下来的版本中会解决。

oracle  的同步方式 主要有几个缺点:

1 .  目前的配置不够灵活  ， 如复制个别表，个别列 ，数据库之间互相复制等
2.   异构平台不能复制 ， 而且以后的复制将不仅仅局限于数据库-数据库之间 ， 数据库到队列 ，数据库到memcache 等

  自己实现一个shareplex 类似的软件也并不难， 如果把整个软件想象成 ETL (数据抽取 ，数据复制 ，数据加载)
那么

1.  数据抽取 。  这边的数据抽取其实就是解析oracle 的log 了 ， 解析log 可以借助于oracle 的 dump 工具，主要的难点是行链接/迁移部分 ，但是只要采用了足够多的样本，就会知道oracle 处理行链接/行迁移的规则 ，从而还原出sql .  解决了 oracle 9i 的日志格式 ，处理10g,11g 的日志就简单很多了 ，10g,11g 里面做了些调整和优化 ，但是改动并不是很大 .
2. 数据传输 。 这个没什么好说的 ，无非是 socket 编程 ，如果做优化的话 可能就是并发传输 。
3 数据加载 。 这一部分设计其实是决定一个复制软件效率的关键地方。  因为log 解析部分不会是瓶颈 ,总共就一个lgwr 在写 ，搞一个程序去解析online redelog 基本没有问题的 。 那么解决加载自然就想到了并发加载 ， 这里面的并发设计方案还是比较多的。

另外还有一个细节 就是 程序的容错性和监控方面的设计 。 容错性 主要是当任何一个复制环节发生问题的时候 能够从断点继续恢复 ，这点从技术上实现并不难，可以把数据、队列保存在磁盘上做持久化。 监控方面一个是人性化设计 ，技术方面主要是通过共享内存来实现 ，其他没什么 。

另外复制要解决的一个问题是 同步数据的初始化 ， 这个方案也很多 。

只要在加载方面做的足够快 ， 打败shareplex 也不是什么难事

Yong Huang

原帖由 lc7888 于 2009-6-17 09:05 发表
首先坦白一下，我是Quest中国公司的人，所以了解得会多一些。
Quest是从oracle7开始用这种方式作oracle数据复制的，按照我们研发部门的说法，Oracle新版本推出后，会给我们研发部门有一个专门的培训，所以我们可以在最短的时间内实现对oracle最新版本的支持。

I think Oracle has some kind of partnetship with some software companies. When Oracle has a newer version, they notify the partners about new format or APIs accessing generally unpublished data. Redo log format may be one of them. TNS protocol may be another. I recently went to a DataDirect seminar. They know how to interpret TNS. I doubt they do it by reverse engineering, although that's not terribly difficult. The seminar speaker told me they get information from Oracle directly. I hope he's speaking truth.

Yong Huang

lc7888

原帖由 fxyj2008 于 2009-6-19 00:25 发表
11g 的 ACTIVE standby 确实不错的 ， 但目前 还是有不少bug  ，相信oracle 在接下来的版本中会解决。

oracle  的同步方式 主要有几个缺点:

1 .  目前的配置不够灵活  ， 如复制个别表，个别列 ，数据库之间互相复制等
2.   异构平台不能复制 ， 而且以后的复制将不仅仅局限于数据库-数据库之间 ， 数据库到队列 ，数据库到memcache 等

  自己实现一个shareplex 类似的软件也并不难， 如果把整个软件想象成 ETL (数据抽取 ，数据复制 ，数据加载)
那么

1.  数据抽取 。  这边的数据抽取其实就是解析oracle 的log 了 ， 解析log 可以借助于oracle 的 dump 工具，主要的难点是行链接/迁移部分 ，但是只要采用了足够多的样本，就会知道oracle 处理行链接/行迁移的规则 ，从而还原出sql .  解决了 oracle 9i 的日志格式 ，处理10g,11g 的日志就简单很多了 ，10g,11g 里面做了些调整和优化 ，但是改动并不是很大 .
2. 数据传输 。 这个没什么好说的 ，无非是 socket 编程 ，如果做优化的话 可能就是并发传输 。
3 数据加载 。 这一部分设计其实是决定一个复制软件效率的关键地方。  因为log 解析部分不会是瓶颈 ,总共就一个lgwr 在写 ，搞一个程序去解析online redelog 基本没有问题的 。 那么解决加载自然就想到了并发加载 ， 这里面的并发设计方案还是比较多的。

另外还有一个细节 就是 程序的容错性和监控方面的设计 。 容错性 主要是当任何一个复制环节发生问题的时候 能够从断点继续恢复 ，这点从技术上实现并不难，可以把数据、队列保存在磁盘上做持久化。 监控方面一个是人性化设计 ，技术方面主要是通过共享内存来实现 ，其他没什么 。

另外复制要解决的一个问题是 同步数据的初始化 ， 这个方案也很多 。

只要在加载方面做的足够快 ， 打败shareplex 也不是什么难事

回复一下哈：
1、数据抽取实际并不是SharePlex最核心的技术，只能算是主要的技术之一，据我所知，阿里巴巴的几个高手已经自己写出了从redo里面抽取数据的程序，但目前还是没办法完全实现数据的复制。其实如何保障事务的一致性，如何保障大并发、大数据量下的性能，如何支持Oracle里面的各种特殊数据类型，如何支持多种操作系统平台等等，都是需要很大的投入，相比较起来，解析日志只是很少的一部分了。另外，你提到的行链接、行迁移早已经不是问题，因为Oracle9i以后的补充日志打开后，这部分信息完全可以从redo中捕捉到。
2、SharePlex的数据传输类似于消息中间间的方式，不过既要保证性能，又要保证各种意外情况下数据不回损失、并可自动恢复，还是需要一些研究的。
3、数据加载确实是一个难点，如何实现并发的处理，并保障数据的一致性，还有，如何定位目标数据库的记录也是一个问题，因为源端的roid在目标段是不可用的。这一点SharePlex和其他的复制软件也分别选择了各自认为最好的方式。目前SharePlex处理的最大数据量是每天800Gb-1.5Tb的归档日志，所以如何在高性能的情况下，保障对资源的占用足够低也是一个很大的难点。
其实你描述的只是一个复制软件最基本的功能，并不难理解，但真正去做一个产品的时候，会发现要复杂得多。其他还有在线的数据比较、修复，DDL的复制，行级或列级的选择复制等等……
初始化同步SharePlex采用了根Oracle的备份恢复或exp/imp结合的方式，来实现在线的初始化同步，这个原理也很简单，只是实际实现起来要复杂得多。
实际打败SharePlex本来就不是什么难事，只是其他人不肯付出这么大的代价去做这些研究和开发，而Quest的优势就是10年前就已经开始做，而且每年都有大量的研发和测试的投入，才能保障现在领先的地位。举个例子，SharePlex每个版本发布之前，至少有3-4个月的内部测试时间，以验证在所有平台和支持的数据库版本上的稳定性。这不是每个厂家都肯去做的。更不要说7*24小时的支持中心，这些都是一个成熟产品最基本的要求。
最后总结一下，其实Oracle目前在这个领域上的落后，绝对不是技术实力不足，而是重视程度不够，呵呵。

viadeazhu

lc7888在quest做开发相关还是技术支持相关呢？
我同意一款成熟的产品的initial effort是不难的，但真正深入起来其实很困难。
所以shareplex做的很不错了，只是还是时不时一些bug。。。