tft每日頭條

 > 圖文

 > sqlserver的監控和診斷

sqlserver的監控和診斷

圖文 更新时间:2024-09-27 12:11:25

有些人經曆這個過程可能比較短,但是多數人經曆的都會比較長。一般數據庫理論知識的積累可能會比較快,但是真正要從理論聯系到實際工作,再從實際工作中反推理論,還真就是一個很漫長的過程。

任何數據庫不達到一定的體量,很多問題就不會發生,那你也就難有機會去處理這些問題。一個DBA經曆了大體量、大訪問量數據庫的磨練,處理了線上極其複雜的問題後,才能真正得到理論和實踐的相結合,從而蛻變成一名合格而優秀的DBA。

sqlserver的監控和診斷(一次生産事故應急處理)1

不積跬步,無以至千裡;不積小流,無以成江海。

就讓我們從日常運維工作,開始慢慢了解SQLServer數據庫。

sqlserver的監控和診斷(一次生産事故應急處理)2

線上故障

對于一個新手DBA來說,數據庫在正常運行下,可能每天的主要任務就是做好備份,執行SQL,優化SQL等日常操作。但是如果突發了數據庫的線上故障,卻是最要命的。

本人在剛成為SQLServer DBA的時候并沒有人帶,完全是靠自己一步步走過來的。

sqlserver的監控和診斷(一次生産事故應急處理)3

先就一個線上故障的案例,來簡單說說如何處理線上問題。

已經記不起當時自己是如何處理第一次線上故障的,就拿平時工作中比較常見的線上故障案例來做分析。

一次早上業務告警,訪問非常卡。

登錄相應的數據庫服務器,内存和IO正常,數據庫沒死鎖,沒阻塞。CPU暴滿。

從經驗判斷,引起CPU暴滿的多數原因,應該是SQL導緻的。

• 1.全表掃描的SQL。

• 2.數據傾斜導緻的SQL的執行計劃走偏。

• 3.無法通過索引來優化的複雜SQL。

sqlserver的監控和診斷(一次生産事故應急處理)4

解決問題

根據經驗判斷,是SQL導緻的問題。

我們開始解決問題:

開啟SQL Profiler監控。

主要抓消耗CPU資源的SQL語句。一般對業務比較繁忙的數據庫系統CPU參數取值,大于4000。

sqlserver的監控和診斷(一次生産事故應急處理)5

經過監控發現一條SQL語句執行的非常頻繁,而且消耗的CPU資源也很多。

我們再來看看這個SQL語句的執行計劃:

大家可以發現,這個SQL語句在執行的時候 掃描表消耗了大量的邏輯讀,所以消耗CPU是很厲害的,證明一定沒有走條件索引。

sqlserver的監控和診斷(一次生産事故應急處理)6

我們對條件字段加上索引。

發現這個SQL的邏輯讀大幅度下降。SQL執行效率也得到了大幅提升。

CPU消耗恢複正常,業務也恢複正常了。

sqlserver的監控和診斷(一次生産事故應急處理)7

sqlserver的監控和診斷(一次生産事故應急處理)8

剖析問題的核心關鍵點

大家可能會說,這個問題解決起來不是很簡單嗎?

對于一個資深DBA來說或許并不難,但是對于一個新手來說,尤其是第一次遇到這類問題的新手DBA來說,想要迅速定位和解決問題,其實并不容易。

因為線上故障發生很突然,而且業務和領導都會催促,你是在很大的壓力之下來處理線上問題的,所以這個過程是需要有過硬的基本功和心理素質的。稍有不慎,一旦處理不當,可能會引起更大的生産事故,那就是災難了。

sqlserver的監控和診斷(一次生産事故應急處理)9

以前遇到過一個DBA在添加windows cluster節點的時候,錯誤地勾選了“将所有符合條件的存儲添加到群集”。

這導緻了整個windows群集報錯無法使用,引起了嚴重的生産事故。

這個錯誤我以前也犯過,還好當時是在半夜,而且不是重要的業務數據庫,當時立即解決了。這位DBA當時很慌張,并且是業務時間,所以并沒有第一時間想到辦法去解決,最後雖然解決了,但是卻影響了業務較長時間的使用。這位DBA也算是比較資深的DBA了,但是在面對突發的生産事故時,同樣會慌不擇路。

sqlserver的監控和診斷(一次生産事故應急處理)10

所以我想告訴各位DBA的同學們,無論你是新手還是資深,對于我們所管理的數據庫系統都要有敬畏之心。尤其對于生産環境的操作,一定要小心小心再小心,因為任何一個生産操作,都可能會導緻巨大的災難。輕則影響業務使用,重則導緻數據丢失。

對于任何不是很确定的操作,一定要在測試環境進行測試,而對于生産環境的操作,一定要有對可能會産生的問題的預判,并做好回退的準備。

而當生産事故一旦發生,我們要做的,無非就是冷靜冷靜再冷靜。

1.一旦發生了生産事故,我們所要做的第一點,就是根據目前所有的監控,去判斷此事故的嚴重性。

2.事故很嚴重,嚴重到影響業務使用,那第一要務就是盡快恢複業務。

• CPU暴滿先從優化SQL着手。

• CPU正常但是磁盤訪問很慢,多半是IO問題,可以考慮進行主備切換。

• 一般硬件問題可以進行主備切換,非硬件問題多半和SQL相關,進行SQL優化。後期再進行業務拆分和讀寫分離。并對可以歸檔的曆史數據進行歸檔。

3.事故不是很嚴重,沒有嚴重影響業務使用,那麼可以先處理優先級高的問題,後面再處理這些問題。

sqlserver的監控和診斷(一次生産事故應急處理)11

寫在最後

本文主要分享了我曾遇到的一次生産事故,應該如何來應對和處理,但是如果我們每次都是充當救火隊員的角色,那對于成為一名稱職和優秀的DBA來說,還是遠遠不夠的。

其實對于SQLServer的日常運維來說,首先要做的,我覺得應該是防患于未然

1.做好數據庫監控,可以使用zabbix監控CPU、内存和磁盤IO等指标,使用Prometheus Grafana,實現可視化界面和SQLServer精細化指标監控和展示。

2.根據SQLServer不同的業務系統,進行數據庫監控指标的告警和通知。

3.對于新上的和老的業務表,都要做好歸檔策略;對于無法歸檔的業務表,要盡早進行業務拆分、分庫分表和讀寫分離。對于不能拆分和分庫分表的業務大表,要盡早進行限制字段的增加。并對開發和業務方提出設計要求,嚴禁業務大表的不斷增長。

4.良好的數據庫設計才是最重要的。對于新上線的數據庫表都要進行規範要求,不合理的設計一定要禁止上線。我們這裡的數據庫表上線,都必須有創建時間和更新時間字段,方便業務後期排查。對于大表的主鍵字段,都建議使用bigint。上線時候最好對索引也有預見,開發可以提出并建立合理的索引。

sqlserver的監控和診斷(一次生産事故應急處理)12

我覺得,一套完整的數據庫監控系統,加上一份良好的數據庫上線規範和數據庫設計,其實就能把線上問題降低和防範一大半了。然後我們自己再深挖數據庫理論,以及進行數據庫優化,那完全可以避免絕大部分線上問題的發生(除去硬件故障)。

其實要說的還很多,但是限于篇幅,暫且就先說到這裡。

做好SQLServer的日常運維隻是第一步,要想在SQLServer上有所建樹,我覺得還是需要深挖SQLServer的原理,畢竟原理通透才是我們DBA的立身之本,然後就是大量實戰經驗的積累了。相信這樣深耕下去,你終會成為一名優秀的SQLServer DBA。

,

更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!

查看全部

相关圖文资讯推荐

热门圖文资讯推荐

网友关注

Copyright 2023-2024 - www.tftnews.com All Rights Reserved