数据库容灾、复制解决方案全分析

herycom

其实我的帖子与其说是技术贴，不如说是技术应用贴。
技术高，但如果不能实用，没有什么用。
各位技术同仁，要注意做一些技术难度不是很大，但对应用有帮助的事情。也许这样价值更大。
另外我的ppt做了少量修改，一些不通顺的语句进行了修改。
这些只是我们实际应用中的一些情况，仅供各位参考，希望能够对各位有些帮助。

herycom

1。传统同步软件方案为10年前的技术，比较落后。
这些技术确实10年前就在使用，而现在确实有更好的技术，所以我保留我的看法。

7。该产品重要的益处，对主机性能影响小。
对主机的影响是我们在实际应用中比较出来的，读全部日志的主要影响在io，而大型数据库的瓶颈也主要是io,华尔东城产品除了只读取关键的数据外，还对数据访问进行自动性能优化。这点刚用oracle自身的产品是不能实现的。

biti_rainy

最初由 herycom 发布
[B]1。传统同步软件方案为10年前的技术，比较落后。
这些技术确实10年前就在使用，而现在确实有更好的技术，所以我保留我的看法。

7。华尔东城产品重要的益处，对主机性能影响小。
对主机的影响是我们在实际应用中比较出来的，读全部日志的主要影响在io，而大型数据库的瓶颈也主要是io,华尔东城产品除了只读取关键的数据外，还对数据访问进行自动性能优化。这点刚用oracle自身的产品是不能实现的。 [/B]

恩，对客户这么描述问题，作为销售或者售前的角色确实不错

但是我们是研究技术的，追究的就是问题的本原，向您这么描述问题，对于我们纯粹做技术的人来说 只能带来疑问

我们需要探讨的就是 如何设计以达到性能和可靠性的,而不仅仅是表现，如果您认为这是商业机密，那对于我们来说除了做点广告外就没多大的意义了。因为这除了影响我们可能的未来的选型上更多地慎重外没别的意义。

herycom

这些是ppt中的资料，这个ppt本来就是销售/售前的资料，这些资料仅供参考。
我本来就是客户方的选型和项目实施人员，不是具体的开发人员，具体软件不是由我开发的，所以我只能说我观察到的现象。
当然我参与了些方案的设计，所以我对整个原理还比较清楚。

biti_rainy

最初由 herycom 发布
[B]这些是ppt中的资料，这个ppt本来就是销售/售前的资料，这些资料仅供参考。
我本来就是客户方的选型和项目实施人员，不是具体的开发人员，具体软件不是由我开发的，所以我只能说我观察到的现象。
当然我参与了些方案的设计，所以我对整个原理还比较清楚。 [/B]

恩，知道原理而不说，那不是吊了大家胃口

biti_rainy

仔细看了下，原来不过是oracle的 mv log 。
从我对这个ppt看来的理解，实际上没有什么技术特点，不过是在管理维护上下了些工夫。通过自己做一些管理界面来维护oracle的复制而已，针对特定的应用实施，有其独特之处，关键要在于合适。因为技术好的不一定就好，主要是适合客户需求。 至于 dsg 或者 shareplex 自然有它独特的使用的场合。oracle的10g的 streams 也不过主张从日志中抽取数据，从10g开始已经逐步不再发展oracle的原来的复制方式。 复制对于多点、网络状况不好、ddl 等存在着严重的缺陷，根据你另外一个帖子来看(http://www.itpub.net/showthread. ... 017&pagenumber=)，实施了一个项目，听了几次oracle的人的介绍，也不用就此否定其他厂家的产品。对于oracle的理解，oracle中国公司的人，未必就比这里的人强多少，他们不过获得内部自然的途径多一些，主要也就多了个 WEB IV 的资料(oracle 的售前支持的工程师在和其他厂家包括teredata/sysbase/db2 争几百个cpu的大单的时候把oracle的弱点暴露在外的例子也有，偶也曾帮助他们从原理及经验上指出过其不足)。修行在个人，oracle 不是三两年就可以精通的,也不是呆在oracle就可以精通的。



另： 该ppt中对 *传统方式的描述*
原理：从日志文件读取数据库变更信息，进行远程数据库更新。目前shareplex、dsj、streams都采用这种方案。
优点：对原来应用对数据库的插入、更新、修改等操作的性能影响较小。（目前大型数据库系统大量采用磁盘阵列，都采用磁盘写cache，写数据的性能不是瓶颈。）
缺点：
无法从根本上保证数据的一致性，漏读日志和目标端的修改都会导致数据不一致。
初始同步需要停止生产系统的数据修改动作，实际操作非常困难。
无法实现双向同步，目标端修改无法反馈到源数据库。
对所有的日志度需要读取分析，对主机数据访问量很大。
该方案技术为10年前的技术，比较落后。
因其本身的缺陷，导致需要大量复杂的机制和操作来保证数据的一致，实施成本大，而且数据完整性最终还是不能完全保证，代价高，成功率比较低。



这些说明其实是不确切的，甚至是刻意误导人的，该技术并不是10年前的，也不落后，日志完全是可以在其他机器上分析不必在主机上进行，对于很多系统，最重要的瓶颈往往就是IO。而显然这个ppt抹零两可地指出了别人的缺点，却对自己的一笔带过。华尔东城准确地说是 做了一个方案而算不上一个有特点的产品，更没必要宣称模仿要被告    。 oracle 的复制才是10多年前就有的技术 。

我们做技术的，就是这样迂腐，总在技术特点上去钻牛角尖

biti_rainy

顺道说一点oracle 的增量刷新：对于 oracle 的 mv log 的增量刷新，不知道大家有多少人研究过增量刷新的本质（通过oracle  sql  trace 可以跟踪出来），kamus 去年写过一个文章讲述这个问题，刷新的本质，就是  mv log 本身就是一个  mlog$ 表，记录了变化数据的主键等信息，然后把这个表和 主表做join 然后读到 刷新目的地，再逐条更新 mlog$ 表中的数据的状态（如果只有一个目的地注册则就是删除）。
原理很简单，你就可以理解为自己用 trigger 记录下了 表变化的数据的pk然后同步到其他数据库。

如果网络状况不好，数据库特别大，第一次刷新的时候将是一个巨大的问题。

wing hong

最初由 biti_rainy 发布
[B]顺道说一点oracle 的增量刷新：对于 oracle 的 mv log 的增量刷新，不知道大家有多少人研究过增量刷新的本质（通过oracle  sql  trace 可以跟踪出来），kamus 去年写过一个文章讲述这个问题，刷新的本质，就是  mv log 本身就是一个  mlog$ 表，记录了变化数据的主键等信息，然后把这个表和 主表做join 然后读到 刷新目的地，再逐条更新 mlog$ 表中的数据的状态（如果只有一个目的地注册则就是删除）。
原理很简单，你就可以理解为自己用 trigger 记录下了 表变化的数据的pk然后同步到其他数据库。

如果网络状况不好，数据库特别大，第一次刷新的时候将是一个巨大的问题。 [/B]

just to make it complete,  in the case of updatable snapshot,  in the delete phase of the fast refresh,  the SQL query to choose the data to delete is a UNION ALL of the mlog$ and the updatable snapshot log ( uslog$) .

biti_rainy

最初由 Kamus 发布
[B]

上周去quest作了一次技术交流
席间也问到了DSG的问题，DSG产品的优势在于效率快，但是确实是可能出现数据不同步的现象，而且据说无法查出原因

至于你说的shareplex同步停止，我不知道你们是怎么测试的，也希望你能说说你们是怎么测试的。
只是最近quest作了一单电信的项目，每天的日志量在峰值的时候是400G，shareplex经过一些方案的修改和调整（具体如何调整quest方面说留带下次技术交流再透露），已经基本上可以应付过来了。

你说“其实 容灾是指应用级负荷分担容灾，不是采用物化视图的方式，是实时同步的。”，我倒是对于这个实时同步的方案很感兴趣，但是你的PPT中几乎没有提到，能不能多说一些。

最后，如果总是持着保留商业机密的想法在这儿讨论，我觉得意义不大。 [/B]

根据另一贴的判断,我猜测 适时的本质是利用  高级复制

yanzr_sb

---------------华尔东城产品除了只读取关键的数据外，还对数据访问进行自动性能优化。这点刚用oracle自身的产品是不能实现。

对于这段话不是很理解。Oracle自身产品不能实现什么样的功能而需要你们的产品来实现自动性能优化？？？

看了PPT，分析就是利用了ORACLE的物化视图技术，外加一些图形界面的配置，好像并无新的东西。

如何没猜错，herycom 该是深圳联通的 一级系统规划工程师 左宗来 同志吧 ？ 根据你留的号码来推测 ： 13322928227
怎么对华尔东城的产品如此认同？你作为技术把关岗位应该对产品提一些问题出来才是啊,