在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. OpenGLES渲染

    OpenGLES渲染 OpenGLES使用GPU渲染图片,不占用CPU,但其使用还是挺复杂的. 先用OpenGLES显示一张图片: // // ShowViewController.m // Open ...

  2. swift版的GCD封装

    swift版的GCD封装 说明 本人针对swift封装了GCD,包括GCDQueue,GCDGroup,GCDTimer以及GCDSemaphore,使用较为便利. 源码 https://github ...

  3. windows 查看端口号,杀进程

    查看端口号: 开始--运行--cmd netstat –and 杀进程: windows任务管理器         查看--显示列-PID 相关知识: 一台机器的80端口被httpd (apache) ...

  4. Oracle判断表、列、主键是否存在的方法

    在编写程序时,数据库结构会经常变化,所以经常需要编写一些数据库脚本,编写完成后需发往现场执行,如果已经存在或者重复执行,有些脚本会报错,所以需要判断其是否存在,现在我就把经常用到的一些判断方法和大家分 ...

  5. 第五周:MySQL数据库

    首先,先了解一下数据库的基本概念要点: 数据库是数据存储的集合,表示数据结构化的信息 列存储表中的信息 行存储表的明细 主键是表中的唯一标识 主键不具备业务意义 在实际操作中,对表的主键不做强制性要求 ...

  6. 在Ubuntu Desktop中安装软件

    1. 安装好虚拟机后,可以先打开firefox,看是否可以访问外部的网页. 2. 如果在公司内网,可能访问不起,需要添加代理,确保可以访问外部的网页. 3. 更新软件源 sudo apt update ...

  7. J - Relief grain HDU - 5029

    Relief grain Time Limit: 10000/5000 MS (Java/Others)    Memory Limit: 100000/100000 K (Java/Others)T ...

  8. [luogu1081] 开车旅行

    题面 ​ 这个题目还是值得思考的. ​ 看到这个题目, 大家应该都想到了这样一个思路, 就是把每个点能够达到的最近的和次近的点都预处理出来, 然后跑就可以了, 现在问题就是难在这个预处理上面, 我们应 ...

  9. 使用 git push 出现error setting certificate verify locations问题记录

    昨天重新装了个系统,使用时出现了error setting certificate verify locations. 出现错误仔细看错误提示,这可是解决问题的关键信息. 将错误的信息复制到搜索引擎中 ...

  10. empty与isset,null与undefined

    一. null VS undefined VS NaN 1. null 定义:null是特殊的object,是空对象,没有任何属性和方法. document.writeln(typeof null); ...