數據庫運維之路——關於tempdb暴增實戰案例

    轉眼間，2021年的第一個季度已經到了最後一個月了，因爲疫情緣由，最近一段時間一直在北京，基本上沒有出差，天天上班下班的日子感受時間過的好快，新的一年繼續努力奮鬥啊。

    仔細回想一下，本身踏入到sql server的領域也已經三年之久了，從剛開始只會簡單的增刪該查，到如今2020年本身支持的一百多家客戶的平常數據庫運維，如今回想一下，仍是成長蠻多的（小誇本身一下）

    如今想經過博客記錄一下個人平常工做狀態，回顧下這幾年來在數據庫遇到的各類各樣的問題，給你們分享一下，歡迎各路大神前來指點。廢話很少說，接下來直接步入主題，---------我在sql  server數據庫的各類實戰問題。

    這個問題我相信你們都遇到過不少次，那就是你們常常談的tempdb數據庫log文件暴增問題，稍不注意，就漲到了幾百個G,甚至更大，嚴重的話還有可能撐爆磁盤，致使業務中止。在平常維護當中，這是個重點關注的問題。

舉例：

下面是我在2020國慶前期給客戶巡檢發現的問題（還好有巡檢），tempdb的log文件從9月21日開始增加，截止到9月30日已經從幾百兆漲到了500G（想一想好可怕），若是國慶前不作此次巡檢，怕不是國慶要出大事情哦。

    看到這一現象，第一時間懷疑就是數據庫中有未提交的事務，致使tempdb的log文件一直暴增，不釋放。這裏邊就有兩種狀況了，一種是已經休眠的會話（sleeping）帶事務,另外就是有一類大的操做用到臨時對象、且作了排序之類的操做。帶着這兩個方向就開始找問題的緣由啦。

    先看看近期有沒有休眠的長時間的會話，點開空閒會話以後，就看到有兩條長時間未提交事務的會話，點開第二條，再看看事務開始的時間，當時內心就想，80%就是它了，9月21日凌晨3點開始的事務，是一我的爲的查詢窗口，

    跟客戶溝通了以後把這個會話殺掉了，tempdb的log文件立馬就掉下來了，經過上面的IP地址找到這臺機器，查詢窗口還在，確實是有人在裏邊開啓了事務，作的相應的操做，最後也忘記關閉窗，既沒有commit也沒有roll  back。因此才致使了此次tempdb的log文件的暴增

 

    這個案例呢，其實也沒有涉及到很複雜的技術，形成這個問題的緣由主要有兩點，第一點是人爲管控，在數據庫管理上要有相應的規章制度。第二呢，就是信息管理人員沒有天天對本身的數據庫作巡檢，還有就是這類的暴增問題也是能夠設置告警的，也不會等到咱們重要節日前的巡檢，才發現此類問題。

 

 固然，關於數據庫運維中還有遇到不少的真實場景，之後會繼續跟你們分享。

 

--------------博客地址-----------------------------------------------------------------------------

 

原文地址: https://www.cnblogs.com/xiong-01/

 

若有轉載請保留原文地址!