我們知道，事務復制是將數據從發布服務器傳到分發服務器然后復制到訂閱服務器的過程 – 數據流幾乎是實時地進行這些步驟。當有問題產生而造成流程中斷，就會出現數據復制延遲。我們經常碰到的難題和關鍵是定位到哪一步是整個延遲的原因。從SQL2005開始支持的
我們知道，事務復制是將數據從發布傳到分發然后復制到訂閱服務器的過程 – 數據流幾乎是實時地進行這些步驟。當有問題產生而造成流程中斷，就會出現數據復制延遲。我們經常碰到的難題和關鍵是定位到哪一步是整個延遲的原因。從sql2005開始支持的跟蹤令牌功能，可以幫助我們輕松確定延遲問題是出現在1）從發布服務器到分發服務器，還是2）從分發服務器到訂閱服務器。
跟蹤令牌
跟蹤令牌是一種特殊的時間戳事務，可以從復制監視器或運行T-SQL語句插入，它會被寫到發布的事務日志中并被日志讀取代理獲取。之后被分發代理讀取并寫到訂閱服務器。每一步的時間戳都被記錄到分發的跟蹤表中并顯示在復制監視器或通過T-SQL語句獲得。見下圖：
在SQL Server Management Studio中，右擊Replication（復制），然后選擇Launch Replication Monitor（啟動復制監視器）。
在復制監視器中，選擇事務復制發布，然后打開Tracer Tokens頁面。點擊Insert Tracer插入新令牌。在插入跟蹤令牌之后，復制監視器顯示“Pending…”。
當日志讀取代理獲取令牌后，它會在分發數據庫的Mstracer_token系統表中記錄時間 – 通過計算插入令牌和日志讀取代理獲得令牌的時間差，來獲得Publisher到Distributor的時間；然后分發代理獲取令牌和并在分發數據庫的Mstracer_history系統表中記錄寫入訂閱方的時間 – 通過計算日志讀取代理獲得令牌和分發代理獲取令牌并寫入訂閱方的時間差，來獲得Distributor到Subscriber的時間。
跟蹤令牌示例
在這個示例中，延遲大約持續了6秒，其中訂閱方的寫入只有1-2秒，但跟蹤令牌卻用了5秒將它們從發布服務器復制到分發服務器。因而，此示例中的事務延遲的關鍵顯然應從日志讀取代理開始而非分發代理。
再來看另一個例子，令牌復制到分發服務器用了3秒，但是到訂閱服務器#1用了1秒，到訂閱服務器#2用了4秒。盡管日志讀取代理不像想象中那么快，但改進到訂閱服務器#2的延遲將可以減少至少一半的整體延遲。
