对大表进行全表更新,导致 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。
对大表进行全表更新,导致 Replication 同步数据的过程十分缓慢的更多相关文章
- 对Big Table进行全表更新,导致 Replication 同步数据的过程十分缓慢
在Publisher database中更新一个big table,数据行数是3.4亿多.由于没有更新 clustered Index key,因此,只产生了3.4亿多个Update Commands ...
- Oracle的大表,小表与全表扫描
大小表区分按照数据量的大小区分: 通常对于小表,Oracle建议通过全表扫描进行数据访问,对于大表则应该通过索引以加快数据查询,当然如果查询要求返回表中大部分或者全部数据,那么全表扫描可能仍然是最好的 ...
- hive 表新增字段后更新分区无法显示数据
解决方案: 1.删除分区后重新跑数据 alter table drop partition(分区字段=“”): 2.新增字段运行程序后其实数据已经有了,只是查询hive的时候无法显示出来, 这个时候只 ...
- Oracle收集对表收集统计信息导致全表扫描直接路径读?
direct path read深入解析 前言 最近碰到一件很奇葩的事情,因为某条SQL执行缓慢,原因是走了笛卡尔(两组大数据结果集),而且笛卡尔还是NL的一个部分,要循环31M次. 很容易发现是统计 ...
- SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析
在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index ...
- SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析 (转载)
在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index ...
- MYSQl 全表扫描以及查询性能
MYSQl 全表扫描以及查询性能 -- 本文章仅用于学习,记录 一. Mysql在一些情况下全表检索比索引查询更快: 1.表格数据很少,使用全表检索会比使用索引检索更快.一般当表格总数据小于10行并且 ...
- MYSQL的全表扫描,主键索引(聚集索引、第一索引),非主键索引(非聚集索引、第二索引),覆盖索引四种不同查询的分析
文章出处:http://inter12.iteye.com/blog/1430144 MYSQL的全表扫描,主键索引(聚集索引.第一索引),非主键索引(非聚集索引.第二索引),覆盖索引四种不同查询的分 ...
- 全表扫描出现db file sequential read
SESSION 1执行 SQL> update test1 set id=1000; SESSION 2 : select * from test1 如果表上面有大量的行迁链接,会是单块读等待事 ...
随机推荐
- Apache下开启SSI配置,使html支持include包含
有的时候,我们的页面有公共的导航栏navbar,公共的脚注footer,那么我们就想把这些公共部分独立成一个html文件,在要引用的地方像引用js,css一样,给包含进来. Apache下开启SSI配 ...
- 连接Mysql错误 error 1042 can't get hostname for your address
背景: 1.etc下的hosts文件有: 127.0.0.1 localhost 2.MySQL的my.ini配置文件: [mysqld] 节点下已经加入以下两行代码 skip-n ...
- zabbix日常监控项mysql(七)
参考文档: percona官方文档:https://www.percona.com/doc/percona-monitoring-plugins/LATEST/zabbix/index.html za ...
- Qt如何设置应用ico图标
第一步,创建ico文件.将ico图标文件复制到工程文件夹目录中(注意必须是图标文件,任何格式的改后缀都不行) ,重命名为"myico.ico“.然后在该目录中右击,新建文本文档,并输入一行代 ...
- HTML5的新标签-整体布局
过去:<div class="header"> <div class="hgroup"> <h1>....</h1&g ...
- 【原创】python __all__ 的用法
1. 写自己的module或者package的时候需要控制向外暴露的名字, 这个很有用, 防止名字污染
- 安装ubuntu server时可能会需要的配置
1.修改源 笔者比较习惯用163的源,配置如下: sudo vi /etc/apt/sources.list 163源为: deb http://mirrors.163.com/ubuntu/ pre ...
- BZ4326 运输计划
Time Limit: 30 Sec Memory Limit: 128 MB Submit: 2132 Solved: 1372 Description 公元 2044 年,人类进入了宇宙纪元.L ...
- ElasticSearch 通过nginx做HTTP验证
在ElasticSearch 的设置文件中如果设置了 network.host: 0.0.0.0 则表示ElasticSearch 服务是公开的任何ip都可以访问ElasticSearch 服务.这样 ...
- 2018 - 2019 CTU Open Contest H. Split Game 【SG函数】
H. Split Game time limit per test 1.0 s memory limit per test 256 MB input standard input output sta ...