在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 同步数据的过程十分缓慢的更多相关文章

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

    在Publisher database中更新一个big table,数据行数是3.4亿多.由于没有更新 clustered Index key,因此,只产生了3.4亿多个Update Commands ...

  2. Oracle的大表,小表与全表扫描

    大小表区分按照数据量的大小区分: 通常对于小表,Oracle建议通过全表扫描进行数据访问,对于大表则应该通过索引以加快数据查询,当然如果查询要求返回表中大部分或者全部数据,那么全表扫描可能仍然是最好的 ...

  3. hive 表新增字段后更新分区无法显示数据

    解决方案: 1.删除分区后重新跑数据 alter table drop partition(分区字段=“”): 2.新增字段运行程序后其实数据已经有了,只是查询hive的时候无法显示出来, 这个时候只 ...

  4. Oracle收集对表收集统计信息导致全表扫描直接路径读?

    direct path read深入解析 前言 最近碰到一件很奇葩的事情,因为某条SQL执行缓慢,原因是走了笛卡尔(两组大数据结果集),而且笛卡尔还是NL的一个部分,要循环31M次. 很容易发现是统计 ...

  5. SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析

    在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index ...

  6. SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析 (转载)

    在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index ...

  7. MYSQl 全表扫描以及查询性能

    MYSQl 全表扫描以及查询性能 -- 本文章仅用于学习,记录 一. Mysql在一些情况下全表检索比索引查询更快: 1.表格数据很少,使用全表检索会比使用索引检索更快.一般当表格总数据小于10行并且 ...

  8. MYSQL的全表扫描,主键索引(聚集索引、第一索引),非主键索引(非聚集索引、第二索引),覆盖索引四种不同查询的分析

    文章出处:http://inter12.iteye.com/blog/1430144 MYSQL的全表扫描,主键索引(聚集索引.第一索引),非主键索引(非聚集索引.第二索引),覆盖索引四种不同查询的分 ...

  9. 全表扫描出现db file sequential read

    SESSION 1执行 SQL> update test1 set id=1000; SESSION 2 : select * from test1 如果表上面有大量的行迁链接,会是单块读等待事 ...

随机推荐

  1. 给UIScrollView添加category实现UIScrollView的轮播效果

    给UIScrollView添加category实现UIScrollView的轮播效果 大家都知道,要给category添加属性是必须通过runtime来实现的,本教程中给UIScrollView添加c ...

  2. GONMarkupParser的使用

    GONMarkupParser的使用 说明 这是一个写得非常好的富文本工具类,便于你进行简易的封装.本人抛砖引玉,只进行了少量的简化使用封装. 效果 源码 https://github.com/nic ...

  3. handsontable 和 echarts都定义了require方法,初始化时冲突了,怎么办?

    echarts初始化时报这个错误. require.config is not a function  方案一: 让其中一方的初始化不依赖于 require即可 1.去掉 var testDrowEc ...

  4. TreeSet 比较器排序 自定义对象

    package cn.itcast.day21.treeset2; import java.util.Comparator; import java.util.TreeSet; /* * TreeSe ...

  5. Hadoop HBase概念学习系列之HBase里的HStore(十九)

    Store在HBase里称为HStore.HStore包括MemStore和StoreFiles.

  6. 解决Struts2 json-plugin Date或Timestamp等日期格式带T的问题

    如果没有对日期时间对象类进行json日期格式声明,会出现类似"2013-06-18T12:08:56.23"日期,在日期中间多出一个T字母: 从通过查询数据,以及调试程序发现直到返 ...

  7. mysql root密码忘记重置及相关注意事项

    1.使用mysqld_safe --skip-grant-tables跳过授权,进入mysql操作界面或者在配置文件mysqld 添加skip-grant-tables也行,找回后需要删除..恢复原样 ...

  8. composer设置国内镜像

    使用composer时,输入命令执行后半天没有反应,并最后是失败的消息. 如下载项目中的框架文件时: composer install 一直没有反应 [注]添加参数-vvv可尽可能多的输出执行信息,帮 ...

  9. MySQL(五)SELECT语句执行顺序

    上一篇讲述了Oracle的SELECT语法的执行顺序,这篇讲述MySQL的SELECT语法的执行顺序.MySQL的SELECT语法的执行顺序和Oracle的基本相同,只是增加了MySQL独有的LIMI ...

  10. ZooKeeper(二)Java API使用

    ZooKeeper官网提供了Java和C的API. 本文使用Java API来实现ZooKeeper的基本操作. 前言 下图中的Replicated Database是包含完整数据树(entire d ...