要解決復制延遲問題，需要首先定位復制延遲發生點，再找出復制延遲的原因，再做相應處理。

復制延遲發生點：1. 發布服務器2. 分發服務器3. 訂閱服務器4. 發布服務器與分發服務器和分發服務器與訂閱服務器之間的網絡

延遲測試方式：1. 使用復制token參考：http://www.cnblogs.com/TeyGao/p/3521130.html

2. 使用復制存儲過程sp_replmonitorhelpXXX

--==========================================================--參考:http://msdn.microsoft.com/zh-cn/library/ms188073.aspx--返回發布服務器上屬于一個或多個發布的訂閱的當前狀態信息，--并為每個返回的訂閱返回一行。 在分發服務器上對分發數據庫--執行此存儲過程，用于監視復制。--@publication_type=0:事務發布--@mode=3:只返回帶錯誤或已生成在達到閾值度量指標時發出的警告的訂閱。EXEC distribution.dbo.sp_replmonitorhelpsubscription  @publisher = null,@publisher_db = null,@publication = null,@publication_type =0,@mode = 3,@topnum = 0,@exclude_anonymous = null,@refreshpolicy = 0--===========================================================--參考:http://msdn.microsoft.com/zh-cn/library/ms186304.aspx--返回發布服務器上一個或多個發布的當前狀態信息。 在分發服務器--的分發數據庫上執行此存儲過程，用于監視復制。--@publication_type=0:事務發布EXEC distribution.dbo.sp_replmonitorhelppublication@publisher = null,@publisher_db = null,@publication = null,@publication_type = 1,@refreshpolicy =0--==============================================================

PS: 某牛X電商使用sp_replmonitorhelpXXX來檢查延遲，不明覺厲。

3. 使用sp_replcounters

--================================================--為每個發布數據庫返回有關滯后時間、吞吐量和事務計--數的復制統計信息。 此存儲過程在發布服務器的任何數--據庫中執行。--參考:http://msdn.microsoft.com/zh-cn/library/ms190486.aspxexec sp_replcounters--================================================

延遲診斷順序：

1. 如果只有一個訂閱延遲，優先檢查該訂閱服務器2. 如果有多個訂閱延遲，優先檢查發布服務器和分發服務器

--==================================================================

發布服務器上延遲分析

原因1： 鏡像或ALWAYS ON 阻塞了復制

診斷方式：使用鏡像監視器或相關存儲過程查看鏡像同步情況

處理建議：

建議A:等待鏡像同步完成或取消鏡像，

建議B:使用TRACE FLAG 1448（慎用）

原因2：磁盤IO存在壓力

診斷方式：使用性能計數器查看日志所在磁盤的磁盤隊列

處理建議:

建議A:提升日志所在磁盤的性能或將日志文件放于獨享磁盤上

原因3：虛擬日志文件數量過多

診斷方式： 使用DBCC LOGINFO來查看虛擬日志數量

處理建議:

建議A: 虛擬日志文件數量應保持一個合理的數量（數量過少和過多都會出現問題）

原因4：數據庫事務日志過多，而復制相關日志較少

診斷方式：

--==========================================================--查看是否因為發布庫日志太多導致日志讀取慢Use <published database>GO-- Total records in the logSELECT count(*) FROM ::fn_dblog(NULL, NULL)GO-- Records marked for REPLICATIONSELECT count(*) FROM ::fn_dblog(NULL, NULL) WHERE Description='REPLICATE'GO

處理建議：

建議A: 設置合理的索引維護及其他會導致大量日志寫入操作的運行時間

建議B: 業務拆分，將與復制不相關的業務拆分出去

原因5：復制發布article上有較大事務運行

診斷方式：

--========================================================--使用發布庫日志來查找大事務--在發布庫上運行SELECT [Transaction ID],COUNT(1) AS LogCountFROM ::fn_dblog(NULL, NULL) WHERE Description='REPLICATE'GROUP BY [Transaction ID]HAVING COUNT(1)>500--===============================================================--在分發庫上查找大事務USE distributionGOSELECT xact_seqno, COUNT(*) AS [COUNT] INTO #MSrepl_commands FROM dbo.MSrepl_commandsGROUP BY xact_seqnoHAVING COUNT(*)>100SELECT t.xact_seqno,t.entry_time,c.[count] FROM MSrepl_Transactions t INNER JOIN#MSrepl_commands c ON t.xact_seqno=c.xact_seqnoORDER BY c.count DESC,t.entry_time

處理建議：

建議A: 按照業務邏輯拆分事務

建議B: 修改復制相關的配置文件設置

--==================================================================

分發服務器上延遲分析

延遲原因1：磁盤IO存在壓力

診斷方式：使用性能計數器查看日志所在磁盤的磁盤隊列

處理建議:

建議A:提升日志所在磁盤的性能或將日志文件放于獨享磁盤上

延遲原因2：分發數據庫寫日志等待

診斷方式：使用DMV查看在分發數據庫上存在寫日志等待

處理建議:

建議A:提高磁盤性能

建議B:將不同的發布服務器拆分到不同的分發庫上，減少分發庫對應的發布數量

延遲原因3：復制分發清理作業和日志讀取代理作業相互阻塞

診斷方式：檢查分發庫上命令數量和事務數量，檢查是否因為復制設置不合理保持過多的事務和命令

參考：http://blogs.msdn.com/b/apgcdsd/archive/2012/09/07/10347168.aspx

處理建議:

建議A: 設置合理的事務保持期和發布屬性設置

建議B: 修改復制分發清理作業的運行時間

延遲原因4：復制事務表和復制命令表包含過多的數據

診斷方式：檢查表中數據分表屬于那些發布article

-=============================================================--當前msrepl_commands表中命令涉及表的分布情況USE distribution;GOWITH cte AS(SELECT  a.xact_seqno,b.entry_time,REPLACE(CONVERT(NVARCHAR(1024),SUBSTRING(a.command,17,1024)),'[dbo].[sp_MS','') commandsFROM dbo.MSrepl_commands a(NOLOCK)JOIN MSrepl_transactions b(NOLOCK)ON a.xact_seqno=b.xact_seqno)SELECT SUBSTRING(commands,9,CHARINDEX(']',commands)-9),COUNT(1)FROM cte WHERE CHARINDEX(']',commands)>9GROUP BY SUBSTRING(commands,9,CHARINDEX(']',commands)-9)ORDER BY COUNT(1) DESC

處理建議:

建議A: 將不同的發布服務器拆分到不同的分發服務器上。

建議B:分析數據變化情況，是否可以減少數據變更

PS: 曾遇到一個案例，按照開發部門需求，搭建復制訂閱，該發布表按天記錄數據，當天數據變化特別頻繁，導致復制延遲較高。調研發現訂閱端業務只訪問前一天數據，于是在發布端新增一張表，每天凌晨將頭一天數據導入此表，并對該表搭建復制訂閱。更改前每天要傳遞數千萬次甚至上億次事務命令給訂閱服務器，更改后只需要傳遞數百萬事務命令道訂閱服務器。

--==================================================================

訂閱服務器上延遲分析

延遲原因1：訂閱庫上有阻塞

診斷方式：使用DMV檢查事務阻塞

處理建議:

建議A：優化訂閱上查詢

建議B：使用較低事務隔離級別或NOLOCK

延遲原因2：訂閱庫日志寫等待

診斷方式：使用DMV查看在分發數據庫上存在寫日志等待

處理建議:

建議A：提高磁盤相應速度。

--==================================================================

相關補充：

1.查看阻塞和資源等待：http://www.cnblogs.com/TeyGao/p/3522958.html

2.查看數據庫文件級別IO操作情況：

SELECT * FROM sys.dm_io_virtual_file_stats(DB_ID(),null) AS T2

--====================================================================