活用md5函数 。 大部分正经的数据库均包含内置的md5函数（PS：无意内涵DB2 ， 真不是故意的） ， 这可以将一个复杂的字符串简化 ， 以便用于运算确认两端的数据一致性 。

九、软件局限性
“越是漂亮的女人就越会骗人 ， 记住啊！”
“不光是漂亮的女人不能相信 ， 连貌似忠良的男人也不能相信 。 ”
我觉得这段对话充分展示了一个产品的售前与售后的结局——殊途同归 。 对于售前来说 ， 拼指标、造场景、讲故事等等手段都是为了证明我家产品很棒 ， 快来买买买；就售后而言 ， 找到产品的痛点 ， 予以规避 ， 以达到保证工作顺利开展 ， 避免一口大锅从天而降的目的 。 大家都是靠博弈而生的 ， 没什么两样 ， 手里的牌均是对技术的了解 。
扯远了 ， 回到it项目中 ， 异构数据库的同步往往是逻辑的同步方式 ， 这种方式必然有各种瓶颈的 。 对售后来说 ， 再怎么谩骂售前“管杀不管埋”也无济于事 ， 最现实的做法莫过于:找到短板 ， 通过改善流程、优化需求甚至协同开发商改造应用的方式保证软件的稳定运行 。
这里先讲个故事 。 Timesten是Oracle的内存数据库 ， 其Cachegroup功能可以实现从物理库（即Oracle DB）到内存库的实时数据同步 ， 而这个同步延迟对业务稳定运行是非常关键的 。 在实际使用中 ， 运维人员总结出的经验就是得规避大事务变更 ， 最终他们与开发商达成相应的操作规范 ， 无论是业务变更需求也好 ， 数据库运维发起的清理作业也罢 ， 如涉及Timestens同步的表 ， 都得遵循变更量达10w万就得分批提交 ， 每个批次2万条记录 ， 每批次之间sleep 30秒的硬性规定 。 我觉得这个故事的结局很完满了 ， 真的 ， 要是换成非得揪着Timesten不放 ， 意图纯粹靠软件解决问题的话 ， 那才是妥妥的灾难现场呢 ， 毕竟其基于trigger的同步机制从原理上就对大事务极不友好……
问题来了 ， 如何找到软件的短板呢？
阅读官方文档自然是一个渠道 ， 当然 ， 阅读也是有“技巧” 的 ：

• 我们支持xx指标以内的场景 ， 这句话可以理解为超过这个您就得想想办法了 ， 同时 ， 这个值也许是要打个折的 ， 毕竟环境不一样 ， 存在差异也是很合理的 。
• 我们支持功能a ， 也支持功能b ， 这都是实话 ， 至于同时支持功能a和b是您自己认为的 ， 我可没说 。

这个嘛 ， 春秋笔法是有的 ， 这种玩法自古就有了 。 陈寿不也没在《三国志》里面明说司马昭弑君吗 ， 后来大家不都知道了吗？
除了文档以外 ， 我们还可以考虑结合自身经验考虑下述点 。

• 大事务测试

分别对同步范围内外的对象做批量操作 ， 加大数据库日志量 ， 观察其对数据同步以及系统的影响 ， 具体包括cpu、内存、io、空间等资源消耗以及同步延迟等 。
以dts为例 ， 源端oracle数据库产生的所有数据均会被拉到dts的库中分析 ， 哪怕这数据与我们的同步策略无关 。
目前有个黑名单功能可以绕过这问题 。

• 长事务测试

包含启动增量同步前开启的事务能否正常同步、长时间未提交的事务是否影响同步进程重启等维度 。
很明显 ，这是被ogg吓到的结果 。

• 频繁事务测试

笔者曾在O2O同步环境中遇到某应用使用了大量with as语法 ， 后者隐式开启了大量的短事务 ， 进而短时间内事务量暴涨 ， 进而 导致同步软件Ogg抽取进程出现延迟 。 这个问题后来找开发商修改语句就解决了 ， 然而其对笔者的心理阴影一直都在 ， 以至于每遇到一个新场景 ， 均会想想会不会遇到类似的问题 。