• Replication:对大表进行全表更新,导致 Replication 同步数据的过程十分缓慢


    在Publisher database中更新一个big table,数据行数是3.4亿多。由于没有更新 clustered Index key,因此,只产生了3.4亿多个Update Commands 和 1个Transaction,数据量还是很大的。在 Log reader 将 Commands 插入到 distribution.dbo.MSrepl_commands 的过程中,几乎所有的Distribution Agent 都抛出 Performance Critical 的Warning,Log Reader 插入Commands的速度十分缓慢,初步预测,仅仅是将Update Commands插入到 MSrepl_commands的时间就需要12hours。为了不影响其他数据的同步,我打算将该表的Publication 和 Subscription 删除,然后手动同步数据。

    Scenario1:

    在Subscriber中,成功删除Subscription。链接到Publisher,在删除Publication时,SSMS 先是 NO Responding,然后报错。查看Subscriber运行的Session,发现 Distribution Agents 的 sessions 都被block。删不掉Publication的原因,估计是Log Reader 正在读取Commands,这个操作不能被异常终止。为了避免损坏其他数据,只能等待 Log Reader 将 Update commands 插入到 distribution中了。Leader只给一天的缓冲期,必须在明天解决这个问题。

    Scenario2:

    在Log Reader 将 Publisher的所有commands都插入到 distribution.dbo.MSrepl_commands 之后,由于在Scenario1已经将Subscription删除,Update Commands没有同步到Target table,但也没有被删除,依然存储在MSrepl_commands中。如果运行 Distribution clean up job,减少 Commands Retition的时间,肯定会影响其他数据的同步。

    EXEC dbo.sp_MSdistribution_cleanup @min_distretention = 0, @max_distretention = 120

    所以,必须手动从 MSrepl_commands 删除相应的commans,同时必须从 distribution.dbo.MSrepl_transactions 删除相应的Transaction。

    根据 MSrepl_transactions 中的 publisher_database_id 和 entry_time,筛选出相应的 xact_seqno(Replication用于同步Commands的事务ID),根据publisher_database_id 和 xact_seqno 查看 MSrepl_commands 的中命令的数量,用以 verify 事务的 xact_seqno。

    select count(0)
    from distribution.dbo.MSrepl_commands with(nolock)
    where xact_seqno=0x000055A8000069610001 and publisher_database_id=19

    也可以使用 sp_browsereplcmds 查看 msrepl_commands 中的SQL语句,最终确定事务的 xact_seqno,根据 publisher_database_id 和 xact_seqno从 distribution 删除commands 和 transaction。

    delete
    from distribution.dbo.MSrepl_commands 
    where xact_seqno=0x000055A8000069610001 and publisher_database_id=19
    
    delete
    from distribution.dbo.MSrepl_transactions
    where xact_seqno=0x000055A8000069610001 and publisher_database_id=19

    耗时 3个小时,终于将commands 和 transaction删除,Replication 恢复正常。
    Mark:在更新Big Table时,最好将 SQL Server Replication关闭,手动在Publisher 和 Subscriber中更新,在更新完成之后,再重建Replication。

  • 相关阅读:
    centos7源以及相关的一些命令
    创建Vue实例的三种方法
    github 钩子管理工具 overcommit
    npm管理registry 【转】
    两个字典增量部分
    celery (二) task调用
    shell编程
    linux 环境变量 转
    celery (二) task
    celery(一) application
  • 原文地址:https://www.cnblogs.com/ljhdo/p/5707199.html
Copyright © 2020-2023  润新知