背景

??從08月21號應用上了新功能以后，CPU idle time 從95%左右斷崖式下降至75%左右，到08-30空閑恢復到90%左右，后面又開始降下來了，因為報警閥值為50%，所以一直也沒有關注到。
??報警突然在上周六晚上23點左右報警低于50%，不過一會就恢復了，當時也沒有太在意，因為知道這個點數據庫有跑批任務，偶爾有CPU負載很正常（DBA的警覺，松懈了），后來在白天也開始斷斷續續的報了起來，自己才覺得不對勁。于是才打開電腦查看了下zabbix 監控報警如下圖，發現了上述的現象，當時驚出一身汗啊，照這樣下去，數據庫服務器離掛不遠了啊。

解決過程

??根據zabbix監控時間段生成了awr報告，DB CPU 占用數據庫100%。

發現問題：

sql_id : 6pkaqzmtgz3za 1小時內執行了27,720,222次；
sql_id : cvaz34tbf38xn 1小時內執行了1,358,576次；
sql_id : d54w1bhvhsbmk 1小時內執行了1,358,555次；
sql_id : 6f8v7rj4xmzgp 1小時內執行了5,579,817次；
內心想法：這四條SQL這是要瘋了差不多1s執行45萬次，這是什么業務這么猛

??因為這4條SQL的單次耗時都是0.幾秒，所以基本不用考慮SQL優化的問題。于是我把這4條SQL情況郵件扔給了開發人員，并提醒了一句：“請盡快解決，目前CPU負載50%-60%，可能會影響數據庫的響應速度，隨時有宕機的風險”，這句很關鍵。
??郵件發出去以后，引起了領導的重視，讓開發盡快確認問題…(此次省備N個字)
??最終發現程序邏輯有個BUG,對處理過的數據狀態未做修改，使程序重復處理相同的數據，造成了死循環。

修復后的CPU idle time 情況：

總結：

??作為DBA對監控的敏感度一定不能松懈，這次幸虧發現的早，一個邏輯死循環很容易把數據庫跑死。AWR報告巡檢每周最少一次，及時發現性能SQL，把問題及時掐滅在萌芽中。。。。第一次經驗總結，希望自己能堅持下去。。。。
?????????????????????????文章推薦