SQLServer：鏡像監控之oldest unsent transaction警示自愈

標籤：sql   server   鏡像   

本文將介紹sqlserver鏡像監控中出現Oldest Unsent Transaction Threshold警示如何自愈

鏡像監控的資料及警示由Database Mirroring Monitor Job作業進行記錄及觸發，當Oldest Unsent Transaction超過Threshold時，觸發代碼為32040的錯誤資訊。

警示的出現可能跟主體伺服器執行個體和鏡像伺服器執行個體中的負載及它們的網路連接相關(博主在維護中遇到的情況大多是這樣)，但是在負載或網路連接恢複正常後，Oldest Unsent Transaction警示資訊依然持續出現，直到backup database或者backup log後，警示才消失。

關於這個問題可在以下串連查看相關詳細資料

Spurious Oldest Unsent Transaction alerts for database mirroring

從執行個體日誌中可知警示資訊如下：

The alert for ‘oldest unsent transaction‘ has been raised. The current value of ‘35‘ surpasses the threshold ‘30‘.

如果是只有一個資料庫配置鏡像，那麼很容易定位出現警示的資料庫；如果是多個資料庫配置鏡像，從警示資訊中，我們無法得知到底是哪個資料庫出現警示。

那麼，實現自愈痛點：

1. 警示資料是哪個

2. 如何計算oldest unsent transaction

通過分析Database Mirroring Monitor Job，我們可以知道Oldest Unsent Transaction警示的出現是由於sys.database_mirroring表的end_of_log_lsn與mirroring_failover_lsn之間相差較大，在Database Mirroring Monitor Job作業中進行Oldest Unsent Transaction計算時結果超出了Threshold，因此觸發警示。

我們先總結一下：

(1) 警示是由於sys.database_mirroring表的end_of_log_lsn與mirroring_failover_lsn之間相差較大導致

(2) Database Mirroring Monitor Job作業能分析並得知是哪個資料庫警示

(3) backup database、backup log後警示會消失

如何擷取警示時的資料庫名，有2種方法：

1. 改寫Database Mirroring Monitor Job作業中相關的預存程序，自訂錯誤碼及資訊

可參考SQL Sentry(SQL哨兵)的支援人員Steve Wright的部落格，有詳細的改寫代碼

2. 提取Database Mirroring Monitor Job作業中相關代碼進行改寫，自訂程式碼片段進行擷取資料

(1)建表

650) this.width=650;" src="https://s1.51cto.com/oss/201711/06/fbe054927cefe561a1b2b0d4d5e5fbef.png-wh_500x0-wm_3-wmp_4-s_1706917713.png" title="51_1.png" alt="fbe054927cefe561a1b2b0d4d5e5fbef.png-wh_" />

(2)收集資料

650) this.width=650;" src="https://s2.51cto.com/oss/201711/06/6688deda0f86c75cdeb5b6e62f0c8c41.png-wh_500x0-wm_3-wmp_4-s_17753087.png" title="51_2.png" alt="6688deda0f86c75cdeb5b6e62f0c8c41.png-wh_" />

擷取到警示相關資料後，我們就可以開始制定相關的“自愈”方案

先決條件(可根據實際情況添加)：

1. 主體與鏡像串連正常

select 

database_id,mirroring_role,mirroring_role_desc,

mirroring_state,mirroring_state_desc,

mirroring_partner_instance,mirroring_partner_name 

from sys.database_mirroring 

where [email protected]_id

2. 主體無長事務正在運行

--查詢執行時間長度超過dbm_monitor_alerts表time_behind閾值的事務

declare @database_id int

declare @time_behind int

set @database_id=5

select @time_behind=time_behind from msdb..dbm_monitor_alerts where [email protected]_id

select count(1) as long_transactions_count from sys.dm_tran_database_transactions dt,sys.dm_tran_active_transactions st

where dt.transaction_id=st.transaction_id

and [email protected]_id

and DATEDIFF(minute, st.transaction_begin_time, GETDATE())>@time_behind 

3. 無備份在運行

SELECT *

FROM sys.dm_exec_requests AS er  

WHERE [email protected]_id 

and er.command in (‘BACKUP LOG‘,‘BACKUP DATABASE‘)

根據先決條件寫成Oldest Unsent Transaction警示自愈指令碼

650) this.width=650;" src="https://s1.51cto.com/oss/201711/06/0af971c0835233c8355651f453b9d867.png-wh_500x0-wm_3-wmp_4-s_2936849611.png" title="51_3.png" alt="0af971c0835233c8355651f453b9d867.png-wh_" />

部署方式：

1. 建立Sql Agent Alerts監控錯誤碼：32040，在Response選項中設定Execute Job為鏡像警示處理作業

2. 在鏡像警示處理作業中第1步為收集資料，第2步為警示自愈

至此，Oldest Unsent Transaction警示自愈已實現，根據實際監控情況進行相關細節的最佳化

本文出自 “aimax” 部落格，轉載請與作者聯絡！

SQLServer：鏡像監控之oldest unsent transaction警示自愈