一次生產事故應急處理｜聊一聊SQLServer DBA

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

任何資料庫不達到一定的體量，很多問題就不會發生，那你也就難有機會去處理這些問題。一個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。