重庆分公司,新征程启航

为企业提供网站建设、域名注册、服务器等服务

对BigTable进行全表更新,导致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。

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

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

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

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


文章标题:对BigTable进行全表更新,导致Replication同步数据的过程十分缓慢
分享地址:http://cqcxhl.com/article/jgijed.html

其他资讯

在线咨询
服务热线
服务热线:028-86922220
TOP