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 2 3 4 5 6 7 8 9 |
--參數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調用操作系統命令
| 1 2 3 4 5 6 7 8 9 10 |
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了或者故障了，可能本機的程序/腳本就無法運行了，又怎麽監控呢？
最後
基於上面的監控列表，還需要將監測工作自動化，並在發現問題時告警。
轉自：http://blog.51cto.com/qianzhang/1256127
sql server監控清單