请教一个关于shareplex的问题

lc7888

QUOTE]最初由 herycom 发布
[B]
啊，shareplex还有这么好的功能，支持7*24小时系统，唉，他们的工程师在我们这试用时怎么不能做到，害我们因不能停止生产系统应用，数据复制中断了好几天。从而放弃了shareplex，可惜。
估计他们没有派厉害的工程师来 [/B][/QUOTE]

当初是我在你们那里做的测试，水平有点差让您见笑了。

shareplex在你们的环境中没办法使用热备份的方法，因为首先你们给我们测试的主机没有足够的存储空间，其次我们测试的也只是计费和营帐系统中的详单表和一些访问量大的表，我们当初提过shareplex可以使用热备的方式，而最后采用exp/imp的方式初始化同步也是你们的工程师决定的。你可以去跟他们了解一下情况。

lojian

如果不通过ROWID, 并且是逻辑复制, 那么对于没有主键的表, SQL中WHERE定位的语句必定是要包括全部字段的吧.
但是日志中如果你不添加附加日志的话,怎么可能作到从日志中获取全部字段,具我所知,日志中的字段除了INSERT和DELTE, 对于UPDATE前镜象只保存了能够确定这行的字段数据,而且ORACLE自己粗略选顶的, 并不一定包括全部行?

我的感觉,shareplex肯定要加附加日志的.
不知道我说的对不对?

samchj

最初由 lojian 发布
[B]如果不通过ROWID, 并且是逻辑复制, 那么对于没有主键的表, SQL中WHERE定位的语句必定是要包括全部字段的吧.
但是日志中如果你不添加附加日志的话,怎么可能作到从日志中获取全部字段,具我所知,日志中的字段除了INSERT和DELTE, 对于UPDATE前镜象只保存了能够确定这行的字段数据,而且ORACLE自己粗略选顶的, 并不一定包括全部行?

我的感觉,shareplex肯定要加附加日志的.
不知道我说的对不对? [/B]

不一定要附加日志，因为在原端和目的端都有代理的话，可以直接通过在原端select得到，然后传送到目的端，但是这样的效率十分低，所以如果shareplex采用这种方式，那么我觉得性能会有影响。

指教！

lc7888

最初由 samchj 发布
[B]

不一定要附加日志，因为在原端和目的端都有代理的话，可以直接通过在原端select得到，然后传送到目的端，但是这样的效率十分低，所以如果shareplex采用这种方式，那么我觉得性能会有影响。

指教！ [/B]

没有附加日志，对于没有主键的表的update,delete，shareplex就是把所有字段当成条件的。
至于对源系统性能的影响可以做到非常低，所有测试过我们产品的用户都可以证实。
如果把原系统和目标系统的roid做一个对应的rowidmap，使用rowid来定位记录，可是这样就需要维护一个非常大的rowid对照表，这样性能就会好吗？

lc7888

最初由 samchj 发布
[B]

我看懂了，因为不能停止系统运行，同时在做首次同步的时候没有太多的时间来运行export导出，因为10g之前的export比较慢，所以首次同步的局限在于必须和原端的数据库一样大，这样herycom的系统根本首次同步都做不了。

换句话说，shareplex比较难完成多到一的数据库复制啊？如果对于不能停机的数据库来说，shareplex可能不太适用吧。

指教！ [/B]

多对一的复制我们有很多实际的项目，实际的实施过程中确实是需要一定的停机时间，但是这样规模的系统建设停机也是很正常的。
在这种情况下，shareplex需要的停机时间就是数据exp的时间。
你能给我举出一个完全没有任何停机时间的数据库吗？我们的至少我们的运营商用户是可以接受我们的实施方式的。

PS:我真的很佩服你的这种主观臆断的分析方式……

lojian

代理是个什么东东?
如果没有附加日志,而且没有主键,也没有ROWID, 怎么确定这行的呢?
你日志读到的时候,这行可能已经没有了,还怎么SELECT出来?
不明白!????

samchj

最初由 lc7888 发布
[B]

没有附加日志，对于没有主键的表的update,delete，shareplex就是把所有字段当成条件的。
至于对源系统性能的影响可以做到非常低，所有测试过我们产品的用户都可以证实。
如果把原系统和目标系统的roid做一个对应的rowidmap，使用rowid来定位记录，可是这样就需要维护一个非常大的rowid对照表，这样性能就会好吗？ [/B]

对原端系统性能确实不会有什么影响，因为日志获取的算法真的很简单，你是对的。

呵呵，rowmap定位未尝不可，只是你知道的算法太简单而已，至少在这种情况下，装载性能要比把所有条件加上快些，呵呵！不信你可以试一试嘛，

samchj

最初由 lc7888 发布
[B]
多对一的复制我们有很多实际的项目，实际的实施过程中确实是需要一定的停机时间，但是这样规模的系统建设停机也是很正常的。
在这种情况下，shareplex需要的停机时间就是数据exp的时间。



你能给我举出一个完全没有任何停机时间的数据库吗？我们的至少我们的运营商用户是可以接受我们的实施方式的。



PS:我真的很佩服你的这种主观臆断的分析方式…… [/B]

嘻嘻，对于多对一的复制，我觉得除了用export/import外，没有办法了，因为不能用热备的方式啊。导出的话可以实现，这是无疑的。停机时间只要项目实施的时候都可以申请到，这不是我们讨论的范围。

至于有没有不需要停机时间的数据库，我可以非常肯定的告诉你，有。只是你真的没有见过而已。

samchj

最初由 lojian 发布
[B]代理是个什么东东?
如果没有附加日志,而且没有主键,也没有ROWID, 怎么确定这行的呢?
你日志读到的时候,这行可能已经没有了,还怎么SELECT出来?
不明白!???? [/B]

代理其实就是一个程序，运行在原端他直接抓取数据库的日志的。运行它需要配置一些参数，当前应该所有的基于逻辑的复制方式，在原端都需要安装个程序的。shareplex/dsg的realsync/以及goldengate。

我刚才想想你说的也对，在日志中的update只有更新那几行的before image，在回滚段中也只有那些，因此，如果要带所有的条件的话，就需要合成一下，怎样取全所有条件是关键，但是update如果我们不计较中间过程的话，只需要最后一次的update数据就可以了，所以其实这里是个比较困难的处理方法，反正我曾经测试过程中发现数据有不准确的情况，当然你也可以自己深入研究一下。

指教！

lojian

最初由 samchj 发布
[B]

代理其实就是一个程序，运行在原端他直接抓取数据库的日志的。运行它需要配置一些参数，当前应该所有的基于逻辑的复制方式，在原端都需要安装个程序的。shareplex/dsg的realsync/以及goldengate。

我刚才想想你说的也对，在日志中的update只有更新那几行的before image，在回滚段中也只有那些，因此，如果要带所有的条件的话，就需要合成一下，怎样取全所有条件是关键，但是update如果我们不计较中间过程的话，只需要最后一次的update数据就可以了，所以其实这里是个比较困难的处理方法，反正我曾经测试过程中发现数据有不准确的情况，当然你也可以自己深入研究一下。

指教！ [/B]

呵呵,谢谢回答.

我想，DATAGUARD的做法是做附加日志.如果想要完全体现数据库的操作历史过程,就不能只处理最后一次UPDATE的数据.

我最关心的是:
如果要求每一步都不差,
UPDATE的before image你们是如何确定的, 因为你们不加附加日志,也不用ROWID, 更不可能从回滚段读, 那么数据来源似乎也只有从源表数据文件里面拿了.难道是创建触发器记录UPDATE的before image?