请教一个关于shareplex的问题

dx6340

shareplex 应该没有用到ROWID。
当初测试的时候把这些sql 语句全部打出来看了的。
用 rowid 为条件这个来作为数据更新查找的条件是绝对不行的。
况且几个T的数据，每一条记录都搞个rowid表来记录，问题多多！

samchj

如果没有rowmap的话，你用rowid做条件有何用，别听sales瞎说。

如果把所有条件当成更新的条件的话，更新速度会十分缓慢是不可避免，而且我觉得也不能是因为这个方法吧。如果是这样方式的话，那我觉得shareplex太笨重了，对于没有主键的表你会无法忍受。

楼上的那位老兄，你可以把你的环境搞出来大家讨论一下，看是你的环境不行还是shareplex不太适用于您现在的环境嘛！

这样免得大家都不服气，呵呵！

samchj

最初由 dx6340 发布
[B]herycom 你看懂lc7888 如何解释的么？？？   RZ ！
不停应用的需要作hot backup 来初始化同步，据lc7888 说你那里的目标机器根本没有那么多的free disk space 来build database , 所以无法用这个方式。

搞了半天看来你对sharpelex 这么不熟悉啊，晕 [/B]

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

换句话说，shareplex比较难完成多到一的数据库复制啊？如果对于不能停机的数据库来说，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定位未尝不可，只是你知道的算法太简单而已，至少在这种情况下，装载性能要比把所有条件加上快些，呵呵！不信你可以试一试嘛，