一. 服務器 1. 狀態監控 (1) 服務器是否可訪問? (2) 相應的數據庫服務是否啟用? (3) 操作系統事件日志中的錯誤或告警 (4) 磁盤可用空間 服務器狀態監控,不管使用第三方工具,還是使用自定義腳本,都建議部署在專門的一臺/多臺監控機上,因為如果服務器DOW
一. 服務器
1. 狀態監控
(1) 服務器是否可訪問?
(2) 相應的數據庫服務是否啟用?
(3) 操作系統事件日志中的錯誤或告警
(4) 磁盤可用空間
服務器狀態監控,不管使用第三方工具,還是使用自定義腳本,都建議部署在專門的一臺/多臺監控機上,因為如果服務器DOWN了或者故障了,任何本機的程序/腳本可能就無法運行了,從而也失去了監控的意義。
甚至有人想過在本機的SQL Server里寫SQL語句來監視服務器狀態,盡管可以實現,但是有點自相矛盾。也許,又會有這么一個思路,服務器正常時,SQL Server就發出郵件通知,如果沒有收到郵件就說明服務器不正常了,可如果有很多服務器時,怎么知道誰沒發郵件呢?
2. 性能監控
(1) IO壓力
(2) 內存使用
(3) CPU使用
(4) 網絡帶寬占用
這1,香港服務器,2,香港服務器,3,4是按照容易出現瓶頸的順序排列的,由于磁盤的讀寫速度限制,通常IO是最容易出現瓶頸的地方,我們所做的很多優化,也都是針對IO的,比如:索引優化,讀寫分離等等。
從DBA的角度來說,服務器的某些性能監控,如果可以的話,從數據庫層來做倒也無妨。
二. 數據庫
1. 狀態監控
(1) 數據庫可否打開 (數據庫狀態)
(2) 數據庫備份有沒有成功
(3) SQL Server/SQL Server Agent錯誤日志中的錯誤或告警
(4) SQL Agent 作業運行狀態
(5) 數據庫一致性檢查的結果 (DBCC CHECKDB)
(6) 數據庫還原測試的結果
以下幾條狀態監控,通常需要和系統平均值/基線值比較才有意義,否則沒有告警的標準。
(7) 連接數、請求數、事務數
(8) 數據庫/文件使用、大小、可用空間
(9) 表使用、行數、占用空間
2. 性能監控
(1) 有沒有長時間運行的查詢 (一般指沒有被任何請求阻塞,效率很差的查詢)
(2) 有沒有被阻塞的查詢 (可能單獨運行很快,但和別的請求一起,由于有鎖等待,耗時很長)
(3) 有沒有死鎖 (開發人員/用戶口中說的”死鎖” 通常是阻塞/等待,數據庫死鎖通常很少讓用戶感覺到等待,香港服務器,一般是請求被中斷,因為被kill掉了)
(4) 有沒有等待 (一般指各種資源的等待,等待和阻塞的交集就是鎖等待)
(5) 有沒有缺失的/未被使用的/效率不高的索引,以及索引碎片
(6) 有沒有過期的統計信息
(7) 有沒有數據庫文件的爭用 (比如:日志文件,tempdb爭用)
(8) 有沒有消耗CPU較大、IO讀寫較多的查詢 (通常IO消耗大的,也就是內存消耗大的查詢)
三. 其他
(1). 如果有部署高可用的策略,會有鏡像、復制、日志傳送、集群狀態的監控;
(2). 某些業務數據有嚴格的一致性要求,業務數據的校驗,最好也做在監控的告警里面;
(3). 對于數據庫/實例的選項、參數設置,登錄、用戶、鏈接服務器等對象的可用性,通常在每年/每季度的health check里檢查過就可以了,如果不放心,當然也可以放到監控的告警中來。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com