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) 數據庫備份有沒有成功

(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_servicecontrolN'Stop', N'SQLServerAGENT'
EXEC xp_servicecontrolN'Start',N'SQLServerAGENT'


(2) SQL調用操作系統命令

if OBJECT_ID('tempdb..#tmp_started_services') is not null
    drop table #tmp_started_services
create table#tmp_started_services(started_servicesvarchar(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了或者故障了,可能本機的程序/腳本就無法運行了,又怎麼監控呢?

 

最後

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


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章