shareplex测试报告

zhangfei__

主要是没有SP测试，要是有测试版的化就好了。

wangxbe

原帖由 Kamus 于 2004-11-25 22:30 发表


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。对于insert into select 是多条SQL，但是对于create table as select则是一条SQL，这就可能成为一个隐患，我在其它的帖子中提到过

不是这样的,问题1的话,比如delete from t where a='xxx'的话,source和target执行的语句是不见得是一样的,比如where条件导致了10条记录被update,那么在source端会执行10次update了1条记录的语句,而不是一条update了10条记录的语句(俺表达能力不行,大家费神好好想想这个意思)

[ 本帖最后由 wangxbe 于 2008-1-29 14:53 编辑 ]

etzhang

GoldenGate 已经被ORACLE 收购了，看来这一块是个肥肉

lc7888

原帖由 Kamus 于 2009-11-13 17:29 发表
5年前的老帖子了。。。那时候的技术讨论氛围还真是很好啊

回顾一下，5年前自己对于Shareplex的很多观点是片面的，大家就权当一听吧。

我也来回顾一下……
5年前你都是啥观点来着？