事務複製問題排查

看到微軟亞太地區區資料庫支援人員組官方部落格發布的5篇針對於事物複製問題排查的部落格，感覺非常有用，這裡引用過來跟大家分享一下。

 

當對事務複製效能問題進行故障排除時，我們可以將資料流分為四段同步的會話，測試每段會話的效能，將有助於確認應該從哪裡開始瓶頸調查。

 

1)  日誌讀取器（LogReader）的讀者線程通過預存程序sp_replcmds（xp_replcmds的封裝）讀取交易記錄，它會掃描被標記為複製事務的日誌，跳過非複製的事務。 2)  日誌讀取器的寫者線程使用sp_MSadd_replcmds，將排隊事務從讀者線程寫到分發資料庫。 3)  分發的讀者線程執行sp_MSget_repl_commands，從散發資料庫獲得未處理的命令並儲存到內部隊列。 4)  分發的寫者線程通過以sp_MSupd、sp_MSins、sp_MSdel開頭的幾個參數化的預存程序，將行的變更應用到訂閱者的每個項目，從而將隊列中的命令寫到訂閱伺服器。 5)  日誌讀取器和散發者也會執行一個“曆史”線程，將總結資料寫到散發資料庫的系統資料表MSlogreader_history和MSdistribution_history中。

接下來我將分五個部分來討論事務複製會話:

1.效能故障排除工具

2.日誌讀取器讀者線程延遲

3.日誌讀取器寫者線程延遲

4.分發代理讀者線程延遲

5.分發代理寫者線程延遲

一、效能故障排除工具

SQLServer事件探查器（SQL
Profiler）：查看事務複製會話的資訊有多種方法。與所有串連到SQL Server的應用程式一樣，複製組件執行的每條命令都可以被事件探查器跟蹤抓取。跟蹤資訊可以被儲存或查詢，從而找到已耗用時間較長的語句。

跟蹤資訊中的“應用程式名稱”舉例：

• REPLICATION     MONITOR —— Management Studio的使用者介面
• REPL-LOGREADER-#-DatabaseName-#——記錄讀取器代理程式向分發表記錄變更的寫者線程
• ServerName\Instance-DatabaseName-PubName-Subscriber——來自分發代理的讀者線程，用於找出哪些命令/事務要複製到訂閱者
• REPLCATION
  LOGREAD HISTORY——記錄讀取器代理程式用來記錄曆史的寫者線程
• REPLICATION
  DISTRIBUTION HISTORY——分發代理用於記錄曆史的寫者線程

複製預存程序調用舉例：

• 分發活動
  • SP_MSGET_REPL_COMMANDS
  • SP_MSHELP_DISTRIBUTION_AGENTID
  • SP_MSGET_SUBSCRIPTION_GUID
• 日誌讀取器活動
  • SP_MSADD_REPLCMDS
  • SP_MSADD_LOGREADER_HISTORY
  • SP_REPLCMDS
  • SP_MSPUB_ADJUST_IDENTITY
  • EXEC SP_MSGET_LAST_TRANSACTION @PUBLISHER_ID = {##}, @PUBLISHER_DB =      {STRN}, @FOR_TRUNCATE = {BS}
  • SP_REPLDONE
  • EXEC SP_REPLCOUNTERS {STRN}
• 訂閱伺服器活動
  • SP_MSins%
  • SP_MSupd%
  • SP_MSdel%

活動監視器（Activity Monitor）：SQL Server Management Studio活動監視器、SQL2005的效能儀錶盤（Performance
Dashboard）、SQL2008的效能資料倉庫（Performance Database Warehouse）、以及系統預存程序，可以協助尋找阻塞、磁碟瓶頸和導致高IO和高CPU的語句。為了識別複製組件，我們可以尋找日誌讀取器或分發代理作業串連到SQL
Server的程式名。尋找複製作業的列表，可運行下面的語句：

SELECT name, description, enabled from MSDB..sysjobs

WHERE category_id>10 and category_id<20

追蹤 Token（Tracer Tokens）：使用複製監視器中的追蹤 Token功能，可以得到複製效能的概覽。該功能提供了“發行伺服器到散發者”以及“散發者到訂閱伺服器”的等待時間值。要使用該功能，開啟複製監視器。在My Publishers表中，選擇想要測試的發布。在右邊的面板，選擇Tracer
Tokens標籤，並點擊“Insert Tracer Token”按鈕。下面將會出現一個訂閱者列表，可獲得“發行伺服器到散發者”和“散發者到訂閱伺服器”的值。

該方法僅對即時複製有用。如果拓撲是晚3天的，那將不會看到追蹤 Token按時到訂閱者，所以，你只能看到日誌讀取器在時間上是否落後。這其實還是很有用的資訊，尤其是在當訂閱者只晚了五分鐘，你可以看到令牌全程傳遞的情況。

如果看到“發行伺服器到散發者”的時間很長，就要集中於日誌讀取器效能的問題排除。如果日誌讀取器效能很好，但“散發者到訂閱伺服器”的值很大，那麼說明，事務從被發行集資料庫的交易記錄到散發資料庫的過程很快，但是從散發資料庫到訂閱資料庫很慢。分發代理應當作為瓶頸調查的關鍵。

下面的連結提供了估計延遲時間的範例程式碼：

• http://www.replicationanswers.com/TracerTokens.asp
• http://blogs.mssqltips.com/blogs/chadboyd/archive/2007/10/24/monitoring-replication-latency-automatically-using-tracer-tokens-sp-replchecklatency-allpubs.aspx
• http://www.microsoft.com/technet/prodtechnol/sql/2005/p2ptranrepl.mspx

效能監控器（Performance Monitor）：我們也可以使用Windows效能監控器來跟蹤複製日誌讀取器的“LogReader:Delivery Latency”計數器或者複製分發的“Dist:Delivery Latency”計數器。不過，Windows效能監控器的複製計數器值僅在日誌讀取器或分發代理完成一個過程階段並記錄了效能狀態之後才會更新。所以即使有一個包含上百萬行的事務在處理，計數器的值也將顯示為0
commands/sec及0 transactions/sec。

 

事務複製會話 (二)

事務複製會話 (三)

事務複製會話 (四)

事務複製會話 (五)