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

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

不積跬步，無以至千裡；不積小流，無以成江海。

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

線上故障

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

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

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

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

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

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

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

• 1.全表掃描的SQL。

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

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

解決問題

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

我們開始解決問題：

開啟SQL Profiler監控。

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

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

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

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

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

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

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

剖析問題的核心關鍵點

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

寫在最後

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

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

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

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

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

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

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

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

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

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