事务复制会话 (三)

三、日志读取器写者线程延迟

 

可能原因：阻塞

日志读取器代理-OUTPUT日志中“write time（ms）”的值很高，表明向分发数据库写命令时有瓶颈问题。阻塞可能是由其他SQL复制代理造成的，比如分发清除代理。我们使用SQL Server内部工具，比如SSMS活动监视器、性能仪表盘（Performance Dashboard）、性能数据仓库（Performance Database Warehouse）或者sp_who存储过程，来查看日志读取器写者线程的阻塞情况。

 

对于SQL 2005性能仪表盘，它提供了一个较高层次查看分发者性能的视角。阻塞、长时间的查询、高IO等待时间都被显示为图形格式。对于SQL 2008，这些报告被包含在性能数据仓库中。

（关于SQL Server 2005 性能仪表盘报告，请参考：https://www.microsoft.com/downloads/details.aspx?familyid=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en）

 

 解决方法：

如果阻塞源（head blocker）是分发清理，请考虑停止这个代理，允许数据先被复制，然后在非高峰时段重新启动清理。阻塞也可能说明IO比预期花费的时间要长。请查看下面的“高IO”来获得更多故障排除步骤。

 

可能原因：高IO

在分发服务器上收集事件探查器跟踪，查看sp_Msadd_replcmds执行的时间长度和CPU值。高IO可能表明有一个比较糟糕的查询计划。使用所抓取的事件探查器跟踪，利用下面的语句来读取已完成事件的CPU和持续时间信息。

 

SELECT duration, starttime, endtime, textdata

FROM ::fn_trace_gettable('C:\DISTRIBUTOR_sp_trace.trc', DEFAULT)

WHERE TEXTDATA LIKE '%SP_MSadd_replcmds%' AND EVENTCLASS=10

 

如何持续时间是CPU时间的十倍，说明资源出现竞争。我们需要在分发服务器上查看日志读取器代理的阻塞情况。

 

SQL 2005和SQL 2008系统的DMV也可以用来获得日志读取器写者线程的持续时间和CPU值。持续时间和CPU值小但逻辑读高，说明可能是一个由数据表统计造成的低效查询计划。下面的命令可以获取查询计划和执行统计。

 

--日志读取器写线程sp_MSadd_replcmds的dm_exec_query_stats

--以top total_worker_time排序

SELECT TOP 25

  st.text, qp.query_plan,

    (qs.total_logical_reads/qs.execution_count) as avg_logical_reads,

    (qs.total_logical_writes/qs.execution_count) as avg_logical_writes,

    (qs.total_physical_reads/qs.execution_count) as avg_phys_reads,

  qs.*

FROM sys.dm_exec_query_stats as qs

         CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st

         CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) as qp

WHERE st.text like 'CREATE PROCEDURE sp_MSadd_replcmds%'

  ORDER BY qs.total_worker_time DESC

                    Go

 

可能原因：写操作IO慢

磁盘子系统慢可能导致较长的写时间。Windows性能监视器的Avg Disk sec/write计数器是对磁盘写性能的一个较好估计。

 

解决方法：

写时间>20ms（.0020）说明有IO写瓶颈，应寻求系统存储厂商进行查看。

 

可能原因：网络IO

与上面的情景一样，你可能需要确定网络接口的队列长度。