事務複製會話 (三)

三、日誌讀取器寫者執行緒延遲

 

可能原因：阻塞

日誌讀取器代理-OUTPUT日誌中“write time（ms）”的值很高，表明向分發資料庫寫命令時有瓶頸問題。阻塞可能是由其他SQL複製代理造成的，比如分發清除代理。我們使用SQL Server內部工具，比如SSMS活動監視器、效能儀表盤（Performance Dashboard）、效能資料倉儲（Performance Database Warehouse）或者sp_who儲存過程，來檢視日誌讀取器寫者執行緒的阻塞情況。

 

對於SQL 2005效能儀表盤，它提供了一個較高層次檢視分發者效能的視角。阻塞、長時間的查詢、高IO等待時間都被顯示為圖形格式。對於SQL 2008，這些報告被包含在效能資料倉儲中。

（關於SQL Server 2005 效能儀表盤報告，請參考：http://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

與上面的情景一樣，你可能需要確定網路介面的佇列長度。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25175503/viewspace-705826/，如需轉載，請註明出處，否則將追究法律責任。