none
SQL 2005 事务同步的差异问题 RRS feed

  • 问题

  • 我用的是事务复制,但是现在存在着数据差异,怎么处理每天的差异数据?能不能让脚本自动处理差异数据?谢谢!
    2009年9月22日 10:24

答案

  • 首先要确定同步的工作是正常的, 可以通过复制监视器进行
    主要检查日志读取代理和分发代理
    然后要确定没有滞后未同步的数据, 主要是分发代理

    如果同步工作没有问题, 那么一般来说不应该有数据差异, 除非你直接操作了订阅的数据, 或者是同步异常时, 你跳过了一些同步数据
    出现数据差异时, 你可以通过 tablediff 这个>=sql 2005的版本提供的小工具来对发布和订阅的表做比较, 这个工具会生成修复差异的脚本, 在订阅端执行脚本就可以修复差异了

    2009年9月23日 4:29
  • 一般来说 只要你的超时连接不会太长 sql server自带会维护的 他是按时间衰减的顺序来传递没有更新过去的事务逻辑
    如果你的网络断开或者不能链接超过3 4天 那么你的复制和同步应该会停止 sql server的性能会严重滞后  所以网络必须要保证
    发生这种情况 最好是手工来维护不一致的数据 然后重新生成快照 建立发布和订阅 

    2009年9月24日 1:36

全部回复

  • You have to find out why data are not in sync.
    2009年9月22日 15:05
  • 参与事务复制中的数据必须是一致的  当然你可以建立链接服务器 
    然后将一边更新的数据同步到另外一边 (不能是发布中的项目)
    而且这个也只能是单边
    2009年9月23日 1:29
  • 滞后是难免的,不过如果长期滞后超过5秒以上,你可能得查下具体什么原因了。譬如网络,是否有冲突需要手工去解决等等。通常同步走专门的网络来保证带宽。
    事务复制外的数据更新,要特别注意不要产生数据冲突;另外如果你有多个订阅的话,情况就更加复杂了。慎用!
    2009年9月23日 2:10
    版主
  • 我使用提是双向事务同步,带宽有时候会连接超时,所以我想知道能用什么办法来解决滞后过期的事务?把没有同步的数据放到一个容器中,然后能不能做一个计划去执行这个容器滞后的数据?ID不会冲突。我每个区域的ID是不同的·
    2009年9月23日 2:14
  • Sql will catch up, why need additional process? If you have bandwidth issue, another container will not help.
    2009年9月23日 2:22
  • 分发库本身就是你说的容器吧。还是得解决源头的问题,如果是带宽的话。
    另外我也遇到过,有些时候事务复制的数据明明是滞后的,但是复制监视器里面还是显示很好,根本不现实滞后,为啥?
    2009年9月23日 2:26
    版主
  • You need check that in distributor agent details.
    2009年9月23日 2:29
  • 首先要确定同步的工作是正常的, 可以通过复制监视器进行
    主要检查日志读取代理和分发代理
    然后要确定没有滞后未同步的数据, 主要是分发代理

    如果同步工作没有问题, 那么一般来说不应该有数据差异, 除非你直接操作了订阅的数据, 或者是同步异常时, 你跳过了一些同步数据
    出现数据差异时, 你可以通过 tablediff 这个>=sql 2005的版本提供的小工具来对发布和订阅的表做比较, 这个工具会生成修复差异的脚本, 在订阅端执行脚本就可以修复差异了

    2009年9月23日 4:29
  • 一般来说 只要你的超时连接不会太长 sql server自带会维护的 他是按时间衰减的顺序来传递没有更新过去的事务逻辑
    如果你的网络断开或者不能链接超过3 4天 那么你的复制和同步应该会停止 sql server的性能会严重滞后  所以网络必须要保证
    发生这种情况 最好是手工来维护不一致的数据 然后重新生成快照 建立发布和订阅 

    2009年9月24日 1:36