shareplex测试报告

lc7888

最初由 Kamus 发布
[B]

0。不强制，但是跟logical standby一样，需要打开incremental logging
1。shareplex只是传输SQL，你这边怎么删除的，他那边用同样的SQL删除，如果你是delete from t where a=xxxx，他那边是一样，如果你这边是循环删除100万条，那么那边就是执行100万个delete语句，这种循环情况下的shareplex效率很低。
2。这个这个无法保证，可以通过order by来保证两边一致
3。上载一个实施shareplex前的检查SQL，这些SQL里面不检查的都是支持的
4。不清楚
5。一条SQL，这就是问题所在，我在其它的帖子中提到过 [/B]

更正一下Kamus 的回复！
0）Shareplex不强制使用主键也不是一定要打开suplemental logging 的方式，打开suplemental logging只是为了提高性能。
1）对于这样的删除，如果原系统做了一条sql语句删除了100万条记录，目标端会执行100条sql,（因为在源系统的redolog里面就是记载了100万条删除语句，而且只有rowid作为条件）每条sql用rownum限制只删掉一条记录，如果原系统的表上有主键，shareplex会把主键当作为一条件到目标端执行，如果没有，就会把所用的字段都当成条件在目标端执行，跟源系统sql的where条件无直接联系，因此shareplex在实施过程中建议用户对经常进行delete和updata 的表在源系统和目标系统上都建主键。
2）与上一条实现方法一样。
3）支持，详情见我上传的shareplex文档，里面包含所有shareplex支持的类型、对象和一些限制。
4）对自治事务不太了解，但shareplex会严格按照源系统的事务一致性来对目标系统进行操作，源系统做的每一个操作他都会复制到目标，原系统提交，他也会提交；原系统如果回退，他也会在目标端执行同样的操作。
5）要看源系统作的insert 操作是怎样做的，shareplex在目标端的处理方法也可能不一样；如果源系统是大量的insert语句，目标端也是一样，如果是create table  as select，目标端就是一句。
6）你的操作是否涉及到主键与shareplex复制的sql无直接联系，如果你仅以rownum为条件进行操作，而你的表上也有主键，shareplex就会把主键当作条件的。从我们目前的测试以及大量的项目实施过程中，在没有人为因素影响的情况下，没有出现过数据一致性的问题。
7）你想知道那种类型的操作在目标端的执行方式？ 我们做过类似的测试，结论已经很清楚了。

以上是我的解释，如果有不清楚的地方欢迎指出！


PS:脚本里面的检查内容只是对数据库环境做一个全面的了解，如果检查的内容都不能复制，那shareplex也没剩多少可以复制的了。另外把人家的内部检查脚本上传是不是有点不太妥当？

lc7888

最初由 Kamus 发布
[B]1.不强制使用主键，也不强制打开suplemental logging ？你确认？不打开suplemental logging 的话，redolog中的记录应该就无法定位。
Supplemental logging must be enabled on the primary database before you create the logical standby database. Because Oracle only logs the columns that were modified, this is not always sufficient to uniquely identify the row that changed and additional (supplemental) information must be put into the redo log. The supplemental information that is added to the redo logs helps log apply services to correctly identify and maintain tables in the logical standby database.
LS是必须要打开的，莫非shareplex有其它的解决方法？

上传那个脚本的时候我也想了一下，觉得这个脚本按照shareplex自己的文档也是完全可以作出来的，无非是用oracle普通的语句检查一下应用，而且让大家都更直观地了解一下shareplex也有不妥吗？当然，毕竟是内部脚本，你有发言权，我已经删除了，呵呵，不好意思。

最后，我说的是脚本中不检查的都是支持，并不是说脚本中检查的都是不支持的，这不是玩文字游戏，我是想说既然脚本有检查那自然就是有某些方面的限制，或者功能上或者性能上，否则也不用特意去检查了对不对？ [/B]

不强制使用主键也不打开suplemental logging 的方式我们也是支持的，8i没有suplemental logging我们也是支持的；suplemental logging 只是会加快我们对行链接和行迁移的情况的处理效率。Shareplex不是仅靠日志里面的内容进行复制的，有些时候他还会需要查询源系统的数据库把一些条件信息加载到从redolog里面取出来的SQL语句中，这一点和LS还是有一些区别的。

lc7888

最初由 Kamus 发布
[B]其实我是就一个客观的态度上来评价shareplex
一个软件有优点自然也就有缺点，优点往往不是我们要说得很清楚的
而缺点才是要探讨一下的，如果大家都知道了有这些缺点，但是仍然不影响应用，OK，那这就是一个好软件。

对于shareplex，我的评价是：
一款很优秀的软件，一个比较完备的oracle数据库同步解决方案，问题在于价格有些昂贵，另外跟应用还是有比较密切的联系，在维护上比Dataguard略显繁琐，当然比起dataguard，比起基于存储的其它同步软件来说优点也是很明显的。

跟dataguard作一下比较：PS=physical standby, LS=logical standby, SP=shareplex
大于号表示优先级，越靠前表示越好
同步同时支持其它应用：SP>LS>PS
同步效率方面：PS>SP>LS
网络传输量方面：SP>PS=LS
管理维护方面：PS>LS>SP
价格方面：PS=LS>SP

个人观点，欢迎lc7888继续讨论 [/B]

你的评价还是很客观的  不同的数据复制方式有些时候很难说孰优孰劣，只能说针对一个特定的场景，哪一个更符合而已，换一个环境，也许就是另外一个产品更合适了。
Shareplex的维护确实要比dataguard或其他存储方案要繁琐一点，这跟它的复制原理是有直接联系的，关键要看Shareplex带来的效益值不值得那些维护工作量了，呵呵。这个就只有让用户自己来决定了。
多谢Kamus对Shareplex的关注和客观的评价，还希望你多提意见，要是只说好听的，大家会认为你被Quest收买了的……

lc7888

最初由 Kamus 发布
[B]

对于这一点偶还是很感兴趣的，希望有机会能更加深入了解一下shareplex在这方面的机制。

BTW：下周可能会跟goldengate的技术人员谈一下。 [/B]

没问题，我们可以在msn上交流，或者有机会见面再聊。
我对goldengate的原理也不是很了解，你们交流后可以在这里给我们介绍一下吗？

biti_rainy

最初由 Kamus 发布
[B]

对于这一点偶还是很感兴趣的，希望有机会能更加深入了解一下shareplex在这方面的机制。

BTW：下周可能会跟goldengate的技术人员谈一下。 [/B]

很明显能根据是否有主键来判别生成sql的方式，就必然用到主库的数据字典信息

lc7888

最初由 Kamus 发布
[B]

我倒是认为shareplex并不会去判断是否有主键
而完全依赖于redo中记录的信息
有无主键的删除，在redo中记录的信息是不一样的

如果每次在translate一个sql的时候都先去检查数据字典，这个效率恐怕会有相当下降。
也就是shareplex翻译出来的sql应该就是redo中记录的，而shareplex不应该会作自己的修改。 [/B]

我们目前可以确认的就是有无主键的时候shareplex在目标端执行的sql语句是不同的，如果有主键，就会把主键当作条件，否则就把所有的字段都当作条件。不管是否打开suplemental logging ，或者是在8i或9i环境下，结果都是这样。
我比较倾向于biti_rainy的观点，怀疑是查询了数据字典，不过从性能上来说应该没有太大的影响，根据我们测试和实施的经验shareplex在源系统上基本不会有问题（在你们那的测试中也可以证明），即使在很大数据量的情况下也是如此。

可以介绍一下有无主键的情况下redo log里面记录的信息有哪些区别吗？因为我用logminer看到的内容是一样的，对update来说只有被修改字段原来的值和rowid当作条件。但没办法确认是否还有其他信息logminer没有显示。
PS:我使用的是toad中的logminer图形化工具。

biti_rainy

最初由 Kamus 发布
[B]

我倒是认为shareplex并不会去判断是否有主键
而完全依赖于redo中记录的信息
有无主键的删除，在redo中记录的信息是不一样的

如果每次在translate一个sql的时候都先去检查数据字典，这个效率恐怕会有相当下降。
也就是shareplex翻译出来的sql应该就是redo中记录的，而shareplex不应该会作自己的修改。 [/B]

你可以做一个有索引无pk约束 和有pk约束的测试 来观察是否有不同，我想使用 dump 看看就应该可以了！

如果把主键信息读出来放到内存里面，是一件很容易的事情。

biti_rainy

最初由 Kamus 发布
[B]

如果说是shareplex把主键信息读出来放到内存中，那么就必定牵涉到定时检查或者事件触发的机制，用来及时更新可能出现的主键修改操作。
lc应该可以咨询一下嘛，呵呵，call一个去美国问问 [/B]

从道理上来讲，一旦发现对 cons$ 的操作  ，或者说在日志中发现增加主键，就维护一下本地内存，也是一个很简单的操作。  这类思想，在我们的即时通讯系统中 用户节点 的的动态维护是一个小case

wlidflower

你这个不是自己测试的吧?如果我没猜错
你应该在做广告了!
这个报告我已经拜读很久的了

davidpan

有没人实际应用Share PLex, 在每天生成60G redo log的数据库中,同步性如何?
准备试下,
顺便问下,有谁知道ORACLE如何记录UNDO信息在redo log 中,却有不太影响DATABASE性能，上次问ＯＲＡＣＬＥ在ＳＨＡＮＧＨＡＩopen world上,说影响可以忽略不计,WHY也没说清.