none
SQLSERVER 2005 复制严重滞后,日志读取器代理正在扫描要复制的命令事务日志... RRS feed

  • 问题

  • SQL版本:Microsoft SQL Server 2005 - 9.00.5057.00 (X64)   

    主库上同步复制到两台同步库,日志代理器是一直有在读,但同步库上的数据严重滞后,看复制监视器,有以下的提示:

    日志读取器代理正在扫描要复制的命令事务日志。在第 3 遍中扫描了大约 500000 个日志记录,占用时间 88795813 (毫秒)。其中,30966 个日志记录被标记为要复制。

    另外,有做发布的数据库每小时有做日志备份,有提示

    已为数据库 'xxxxdb',文件 'xxxxDBLOG2' (位于文件 1 上)处理了 153029 页。 [SQLSTATE 01000] (消息 4035)  该日志未截断,因为其开始处的记录是挂起的复制操作。请确保日志读取器代理正在运行,或使用 sp_repldone 将事务标记为分布式的。

    现在此库的事务日志增长飞快...也变得相当大.

    请教解决方案....

    2012年9月22日 7:45

答案

  • Possible issues: distributor can't send transactions to subscriber quick enough, or subscriber can't apply transactions quick enough, or both. You should run perfmon on both servers to find out root cause.

    2012年9月25日 15:51

全部回复

  • 应该是发布者端在进行大量的日志操作.

    比如一次更次几百万数据等等.

    这样会导致Log Reader一直忙于读.

    造成订阅者滞后


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

    2012年9月22日 7:47
  • 应该是发布者端进行了大量的update操作.

    还有,假如你是alter column的类型,那么会对源表进行update tablename set column=column操作

    这个时候,日志读取器会一直忙于将事务从日志文件中读取到distribution数据库.

    使得订阅者处于滞后状态


    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

    2012年9月22日 7:57
  • 这个是从昨天晚上2:45左右出现的情况...没有做alter column这类的操作.用exec sp_browsereplcmds可以看到非常多的未分发的命令...现在同步数据一直跟不上来..不知道有什么方法能解决.

    还是只能等LOGRreader把大量的事务给读完?

    2012年9月22日 8:05
  • 
    2012年9月22日 9:05
  • 删除复制,备份主库的事务日志(截断日志 ),然后再重新建立复制,这样应该可以

    给我写信: QQ我:点击这里给我发消息


    2012年9月22日 14:54
  • 删除复制,备份主库的事务日志(截断日志 ),然后再重新建立复制,这样应该可以

    给我写信: QQ我:点击这里给我发消息



    What will you do if high latency happens again? Keep resetting replication?
    2012年9月22日 18:39
  • 你好,

    请问你的SQL SERVER 实例是处于集群的情况下吗? 如果是的话, 可以参考下下面这个片KB,或许对你有帮助。

    http://support.microsoft.com/kb/945903

    Thanks.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. This can be beneficial to other community members reading the thread.

    2012年9月24日 8:45
    版主
  • 不能删掉复制。如果重新建复制 ,从库上的数据要被初始化掉,影响业务。业务要求不能停止。
    2012年9月24日 9:43
  • 不是集群哦。。现在看来有点无解的感觉。

    导致问题的原因:

    1、从库的Io性能比不上主库

    2、主库进行了大量的DML操作,导致Log Reader一直忙于读.----这点上有点不解,那主库以后还不能进行大量的update操作了?

    2012年9月24日 9:48
  • LZ应该考虑一下其他的方案,比如事务日志传送


    给我写信: QQ我:点击这里给我发消息


    2012年9月24日 14:30
  • 不是集群哦。。现在看来有点无解的感觉。

    导致问题的原因:

    1、从库的Io性能比不上主库

    2、主库进行了大量的DML操作,导致Log Reader一直忙于读.----这点上有点不解,那主库以后还不能进行大量的update操作了?

    Where did you put distribution db? Possible to put it on its own disk? Where's db log files? Are they on separate disk?

    • 已编辑 rmiao 2012年9月24日 15:10
    2012年9月24日 15:10
  • 这个症状貌似我以前见过,如果可以告诉详情,Email:guohao0826@126.com给我。

    2012年9月24日 15:38
  • 发布和分发都是在本机,使用推送订阅。硬件条件有限,六盘位机器。1块系统,一块SSD放主库,3块磁盘做Raid5,还有1块做备份盘。distribution放在RAID5中。主库有两个LDF,一个在SSD硬盘上,还有一个在Raid5的磁盘阵列上。

    2012年9月25日 0:11
  • 一部机器6个磁盘?两个实例?


    给我写信: QQ我:点击这里给我发消息

    2012年9月25日 1:23
  • 一个实例。
    2012年9月25日 1:45
  • How about disk activities? Possible to move distributor to its own machine?
    2012年9月25日 2:22
  • 主库上的磁盘快列并不大.分发者是在本机.问题在放着跑一天一夜后,从库才慢慢跟上主库
    2012年9月25日 14:57
  • Possible issues: distributor can't send transactions to subscriber quick enough, or subscriber can't apply transactions quick enough, or both. You should run perfmon on both servers to find out root cause.

    2012年9月25日 15:51