Replication--復制延遲的診斷和解決

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

復制延遲發生點：
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
--==============================================================

 

 3. 使用sp_replcounters

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

exec 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 log
SELECT count(*) FROM ::fn_dblog(NULL, NULL)
GO
-- Records marked for REPLICATION
SELECT count(*) FROM ::fn_dblog(NULL, NULL) 
WHERE Description='REPLICATE'
GO

處理建議：

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

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

 

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

診斷方式：

--========================================================
--使用發布庫日志來查找大事務
--在發布庫上運行
SELECT [Transaction ID],COUNT(1) AS LogCount
FROM ::fn_dblog(NULL, NULL) WHERE Description='REPLICATE'
GROUP BY [Transaction ID]
HAVING COUNT(1)>500
--===============================================================
--在分發庫上查找大事務
USE distribution
GO
SELECT xact_seqno, COUNT(*) AS [COUNT] 
INTO #MSrepl_commands FROM dbo.MSrepl_commands
GROUP BY xact_seqno
HAVING COUNT(*)>100
SELECT t.xact_seqno,t.entry_time,c.[count] 
FROM MSrepl_Transactions t INNER JOIN
#MSrepl_commands c ON t.xact_seqno=c.xact_seqno
ORDER 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;
GO
WITH cte AS(
SELECT  a.xact_seqno,b.entry_time,
REPLACE(CONVERT(NVARCHAR(1024),
SUBSTRING(a.command,17,1024)),'[dbo].[sp_MS','') commands
FROM 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)>9
GROUP 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

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