0. SQL Server監控清單

標籤：style   blog   http   color   os   io   使用   ar   strong   

原文:0. SQL Server監控清單

資料庫伺服器的監控可大致分為兩類：

(1) 狀態監控：資料庫伺服器有沒有在健康地運行？

(2) 效能監控：健康啟動並執行同時，有沒有效能問題？可不可以更快些？

 

一. 伺服器

1. 狀態監控

(1) 伺服器是否可訪問？

(2) 資料庫服務是否啟用？

(3) 作業系統事件記錄中的錯誤或警示

(4) 磁碟可用空間

 

2. 效能監控

(1) IO壓力

(2) 記憶體使用量

(3) CPU使用

(4) 網路頻寬佔用

這1，2，3，4是按照容易出現瓶頸的順序排列的，由於磁碟的讀寫速度限制，通常IO是最容易出現瓶頸的地方，我們所做的很多最佳化，也都是針對IO的，比如：索引最佳化，讀寫分離等等。

 

二. 資料庫

1. 狀態監控

(1) 資料庫可否開啟 (資料庫狀態)

(2) SQL Server/SQL Server Agent錯誤記錄檔中的錯誤或警示

(3) 資料庫/檔案組可用空間

(4) SQL Agent 作業運行狀態

(5) Database Backup有沒有成功

(6) 資料庫還原測試的結果

(7) 資料庫一致性檢查的結果 (DBCC CHECKDB)

 

以下幾條狀態監控，通常需要和系統平均值/基準值比較才有意義，否則沒有警示的標準。

(8) 串連數、請求數、事務數、線程數

(9) 資料庫/檔案/表的大小

(10) 表使用、行數

 

2. 效能監控

(1) 有沒有長時間啟動並執行查詢 (一般指沒有被任何請求阻塞，效率很差的查詢)

(2) 有沒有被阻塞的查詢 (可能單獨運行很快，但和別的請求一起，由於有鎖等待，耗時很長)

(3) 有沒有死結 (開發人員/使用者口中說的”死結” 通常是阻塞/等待，資料庫死結通常很少讓使用者感覺到等待，一般是請求被中斷，因為被kill掉了)

(4) 有沒有等待 (一般指各種資源的等待，等待和阻塞的交集就是鎖等待)

(5) 有沒有缺失的/未被使用的/效率不高的索引，以及索引片段

(6) 有沒有到期的統計資訊

(7) 有沒有資料庫檔案的爭用 (比如：記錄檔，tempdb爭用)

(8) 有沒有消耗CPU較大、IO讀寫較多的查詢 (通常IO消耗大的，也就是記憶體消耗大的查詢)

 

三. 其他

(1). 如果有部署高可用的策略，會有鏡像、複製、記錄傳送、叢集狀態的監控；

(2). 某些業務資料有嚴格的一致性要求，業務資料的校正，最好也做在監控的警示裡面；

(3). 對於資料庫/執行個體的選項、參數設定，連結的伺服器等對象的可用性，通常在每年/每季度的health check裡檢查過就可以了，如果不放心，當然也可以放到監控的警示中來。

 

四. 如何部署監控？

1. 不要選擇依賴性的指令碼/命令

以監視服務是否啟動為例，指令碼如下：

(1) SQL擴充預存程序

--參數1: QueryState 檢查服務狀態/ Start啟動服務/ Stop停掉服務--參數2: 服務名exec master.dbo.xp_servicecontrol ‘QueryState‘, ‘MSSQLServer‘exec master.dbo.xp_servicecontrol ‘QueryState‘, ‘SQLServerAgent‘exec master.dbo.xp_servicecontrol ‘QueryState‘, ‘SQLBrowser‘exec master.dbo.xp_servicecontrol ‘QueryState‘, ‘NetLogon‘EXEC xp_servicecontrol N‘Stop‘, N‘SQLServerAGENT‘EXEC xp_servicecontrol N‘Start‘,N‘SQLServerAGENT‘

 

 (2) SQL叫用作業系統命令

if OBJECT_ID(‘tempdb..#tmp_started_services‘) is not null    drop table #tmp_started_servicescreate table #tmp_started_services (started_services varchar(255))insert into #tmp_started_services(started_services)   exec master..xp_cmdshell ‘net start‘ select *   from #tmp_started_services  where LTRIM(RTRIM(started_services)) like ‘SQL%‘

如果SQL Server沒啟動，這些指令碼根本就跑不了，又怎麼監控呢？

也許，又會有這麼一個思路，伺服器正常時，發出郵件通知，如果沒有收到郵件就說明伺服器不正常了，可如果有很多伺服器時，怎麼知道誰沒發郵件呢？

 

2. 部署在專門的一台/多台監控機上

伺服器狀態監控，不管使用第三方工具，還是使用自訂指令碼，都建議部署在專門的監控機上，遠程監視目標機器。

因為：如果伺服器DOWN了或者故障了，可能原生程式/指令碼就無法運行了，又怎麼監控呢？

 

最後

基於上面的監控列表，還要需要將監測工作自動化，並在發現問題時警示。

 

0. SQL Server監控清單