作者：羅貴林

原文鏈接：https://mp.weixin.qq.com/s/2e5eKSoGlU9J4Rjq1zwLnw

導讀：在使用數據庫的過程中，內存不足常常會引起數據庫異常。但是內存不足，又會為數據庫帶來哪些具體的影響呢？本次，我們將通過某客戶現場數據庫在某個時段內性能嚴重下降的案例來展示由于主機內存不足而造成數據庫日志寫入卡頓的問題分析過程。通過本案例，我們也可以對相關問題的分析方法及解決建議有一些深入的了解。

問題描述

---

2020年1月15號凌晨2點左右客戶產線異常，應用后臺消息報錯業務處理超時。此外，在16號凌晨2點左右和下午2點左右，也發生業務處理超時，影響較大。

故障時段數據庫的等待事件信息如下：

問題分析

---

查看數據庫故障時間段的ash信息，可以看到確實在1：56~1：57分的時候，等待比較嚴重：

select trunc(sample_time, 'mi'), count(1)

from gv$active_session_history

where sample_time >= to_date('2020-01-16 01:50:00', 'yyyy-mm-dd hh24:mi:ss')

and sample_time < to_date('2020-01-16 01:59:00', 'yyyy-mm-dd hh24:mi:ss')

and event is not null

group by trunc(sample_time, 'mi')

order by 1;

2. 進一步分析等待事件，可以看到log file sync等待排名第一，而其他等待事件很少。因此主要是log filesync等待事件發了超時：

select inst_id, event, count(1)

from gv$active_session_history

where sample_time >=

to_date('2020-01-16 01:50:00', 'yyyy-mm-dd hh24:mi:ss')

and sample_time <

to_date('2020-01-16 01:58:00', 'yyyy-mm-dd hh24:mi:ss')

and event is not null

group by inst_id, event

order by 1, 3 desc;

3. 進一步查看lgwr 的 trace，但沒有發現異常信息。

4. 繼續查看log file sync等待信息，可以看到都是被同一條SQL的會話阻塞。該SQL對應的文本為insert into xxx……，是用于業務寫日志的語句，體現在應用日志上就是卡在進程剛開始的時候超時的執行。

5. 由于告警日志和LGWR TRACE里都沒有異常信息，于是我們可以查看那條SQL的執行情況，發現故障時點每次執行時間變長了。

6. 繼續查詢故障時段log file sync、LGWR wait for redo copy等待事件直方圖信息。從這條insert sql執行歷史信息，調用次數并沒有突增的情況，但是log filesync/LGWR wait for redo copy等待抖動比較嚴重：

根據故障處理經驗來判斷，LGWR抖動比較嚴重，懷疑物理IO出現了問題。

7. 分析排查物理IO問題，IO沒看到異常情況，所以在這里排除了IO引起的日志寫入抖動的問題。

8. 查詢故障時段SQL占用CPU排名的情況

而該sql_id的sql_text則是：

對故障時間點的ASH報告進行分析，故障時間點這個select 1 from dual占用的cpu最高，這個sql一般是weblogic等中間件測試連接池連接用的，一般不會引起CPU的使用問題，且總體CPU使用率并沒有撐滿。故在這里可以排除CPU使用影響的情況，由于這套數據庫平時內存的使用率就是98%左右，只剩2G空閑內存，而故障時點，只剩幾百兆內存。

因此，分析到這里基本可以定位是內存消耗過高引起的問題，這里考慮到觸發故障的時間點有高度規律性，于是考慮可能是由于一些定時任務引起的，于是檢查了crontab，job定時任務、備份等，但都沒發現有故障時間的運行的信息。

這個時候考慮數據庫主機層面上定時任務和進程分析一些信息，由于以前出現故障的時候，有讓客戶開啟oswatch采集，故這次也同樣從osw中top的采樣時間進行檢查，且最終發現在異常時osw的采樣時間也變長了，說明故障出現的時候整個操作系統都有受影響。

9. 查看osw中ps的信息

將osw采樣的時間加大到42秒的和正常15秒內的兩個時間進行比對，可以發現故障出現的事件點內，多出來的一個進程是CVU的JAVA進程。故懷疑是cvu的java進程對主機的內存造成了大量的消耗。

查看cvu的運行日志，可以看到cvu是6小時執行一次，而在1：56和13:56的時候主機確實都運行了這個進程。當然，cvu服務停用并不影響數據庫實例正常使用，只是在運行cluvfy時有調用到，而在01:56:25~01:57:07這個中間系統中是卡著的，且內存的free一直減少。

從vmstat上看，也驗證了異常時主要是內存問題，交換空間頁面切換和系統調用次數也在加大。

綜合以上的分析，可以確認是cvu定時調用導致內存消耗過大，而內存本身就不足，在調用的那一瞬間引起了數據庫主機內存抖動，引起了數據庫主機的卡頓，臨時處理方法是停止cvu服務，在之后的跟蹤中沒有發現同樣的故障發生，故障處理完成。

cvu定時任務是集群軟件調用cvu工具定時檢查集群運行狀態，記錄到日志文件中的。它的運行導致現有服務器內存資源過于緊張，導致幾乎所有進程都變慢。

問題解決

---

本次案例出現的主要原因是由于cvu定時任務進程的調用導致現有服務器內存資源過于緊張，引起了數據庫主機內存抖動，造成數據庫卡頓。臨時處理方法是停止cvu服務，在之后的跟蹤中沒有發現同樣的故障發生，故障處理完成。

想了解更多關于數據庫、云技術的內容嗎？

快來關注“數據和云"、"云和恩墨，"公眾號及"云和恩墨"官方網站，我們期待大家一同學習與進步！

小程序”DBASK“在線問答，隨時解惑，歡迎了解和關注！

總結

以上是生活随笔為你收集整理的sql 2008服务器内存一直居高不下_经验之谈：内存问题造成数据库性能异常怎么破？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。