SQLServer 可更新订阅的订阅库数据未同步到发布库查看

刚更新几行数据，同事查到一个分库的数据未同步到总库。于是想到是不是同步出现什么错误了。

在发布实例中打开 “复制监视器” ，没发现有错误，队列读取器、日志读取器、分发都正常同步数据。

发布数据库没有错误，想到可能是订阅数据传递堵住了。

查看订阅数据库等待同步到发布的事务和命令数：

SELECT COUNT(*)  FROM [Platform].[dbo].[MSrepl_queuedtraninfo](NOLOCK)
SELECT COUNT(*)  FROM [Platform].[dbo].[MSreplication_queue](NOLOCK)

果然，有堵住，该订阅分库的队列一直在增加。是不是资源正在被其他进程访问？

--检查当前存在的堵塞（blocked =0 为堵塞的session，多执行几次查看）
select p.*,s.text from master.dbo.sysprocesses p cross apply sys.dm_exec_sql_text(p.sql_handle) s
where blocked > 0 or spid in(select blocked from master.dbo.sysprocesses where blocked > 0)

也没有堵塞，是不是CPU申请不到？看看当前在执行什么操作：

SELECT
[session_id],
[blocking_session_id] AS '正在阻塞其他会话的会话ID',
[request_id],
[start_time] AS '开始时间',
[status] AS '状态',
[command] AS '命令',
dest.[text] AS 'sql语句', 
DB_NAME([database_id]) AS '数据库名',
[wait_type] AS '等待资源类型',
[wait_time] AS '等待时间',
[wait_resource] AS '等待的资源',
[reads] AS '物理读次数',
[writes] AS '写次数',
[logical_reads] AS '逻辑读次数',
[row_count] AS '返回结果行数'
FROM sys.[dm_exec_requests] AS der 
CROSS APPLY  sys.[dm_exec_sql_text](der.[sql_handle]) AS dest 
WHERE [session_id]>50 AND DB_NAME(der.[database_id])='platform' and session_id<>@@SPID
ORDER BY [cpu_time] DESC

select p.*,s.text from master.dbo.sysprocesses p cross apply sys.dm_exec_sql_text(p.sql_handle) s
where spid=154

发现等待的类型是 ASYNC_NETWORK_IO ，意思是数据已经准备好了，但是网络并没有完全取走结果集。suspended 表示CPU正等待资源。而等待的 sql 语句为 sys.sp_replsqlqgetrows ，即表示正在从等待同步的事务表和命令表中获取数据，是什么命令导致等待？

（在订阅库）从队列表中按时间查看最早插入到该表的事务，确定为该事务正在执行中…………

SELECT top 5 * FROM [Platform].[dbo].[MSreplication_queue](NOLOCK)order by insertdate

（在订阅库）找到该事务，看看执行了什么命令

--  tranid 为上面查到的事务id
exec sys.sp_replqueuemonitor 'publisher','publisher_db','publication','tranid',0

结果近6万行数据需要同步，command 中有一个存储过程 create procedure [dbo].[sp_MSsync_upd_10C4B6FD_0596_42B0_862B_ED17BFD4BB97] ，但是看不到是哪个表的数据。现在到发布数据库，查看该存储过程的定义。

sp_helptext [sp_MSsync_upd_10C4B6FD_0596_42B0_862B_ED17BFD4BB97]

在存储过程内部查看一下，都可以找到相关表的信息。

知道是该表，也就确定了，因为这个表是数据库中最大的表，分页也会很多，突然更新6万行数据，同步时当然会较久了。十几分钟后，数据同步完整，等待同步的队列也就减少了。没什么问题，虚惊一场！~