码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2017-04-25 15:08:51      阅读:165      评论:0      收藏:0      [点我收藏+]

标签:database   影响   

    

在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。

技术分享

deletefrom distribution.dbo.MSrepl_commands 
where xact_seqno=0x000055A8000069610001 and publisher_database_id=19deletefrom distribution.dbo.MSrepl_transactionswhere xact_seqno=0x000055A8000069610001 and publisher_database_id=19

技术分享

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


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

标签:database   影响   

原文地址:http://hzz333.blog.51cto.com/12844012/1919090

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!