Oracle效能排查小案例

原創文章標籤經驗分享

文章分類oracle

資料庫閱讀數28

昨天乙個老同學找我說碰到了資料庫的問題，因為各種雜事一直給耽誤了下，今天做了乙個初步的分析。

首先這是乙個做統計業務的資料庫，型別可以歸為olap方向。根據反饋，在週末的時候相關的etl任務會卡住，問題已經過去了一段時間，確切的說是發生了10月份的時候了，經過一段時間的排查發現問題是有規律的。所以想讓我看看資料庫層面有哪些潛在的問題，可以把這個問題解決掉。

首先我要到了乙份awr報告。整體看配置還是很不錯的，小機下的11g rac環境，硬體配置也是蠻不錯的。

這裡的db time還是很高的，這也就能夠間接說明是在etl出現問題很可能和這個db time異常是有關的。

看到這裡我需要去明確既然是rac環境，另外乙個節點是否也有類似的問題，結果很快排除了，只在這個節點2上存在效能抖動，節點1上的負載可以忽略不計。

這是節點2乙個概覽資訊。

裡面有幾個指標是很明顯的，比如redo日誌量實在是太高了，整體來看io方面，壓力還是蠻大的。

這個等待事件也是比較典型的，可以更加明確問題的方向了。

按照目前的資訊，可以基本得到乙個資料，每秒產生28m的redo日誌量，那麼1分鐘會產生28*60近1.4g的日誌，如果是乙個小時，產生的redo就有80g左右。

可以看到等待事件，很多也是和redo方向相關的，排在首要的是日誌切換頻率的問題。

這是時間模型的乙個概覽。

基於以上的資訊，我們可以更加關注於io層面相關的sql,結果一看乙個準。

通過這個可以很明顯的看到問題的瓶頸了，原來是有幾個delete語句，經過確認這些delete語句是沒有where條件的，也就意味著這是乙個權標資料的清理，顯然使用truncate是正確的解法。

經過了解，這屬於etl的乙個流程，會先清理掉之前的資料，然後通過繫結變數批量寫入資料的方式，呼叫的頻率都是百萬級別。

報告裡面有一小欄不太起眼，通過這個指標能夠明確的定位到問題。

在1個小時的時間裡，日誌切換了500多次，按照日誌寫入的情況，乙個小時80g左右的日誌，切換500次，那麼redo檔案的大小在150-200m之間，對於目前的這個配置和當前的問題來說，是很不合理的，按照問題發生時的情況，每隔7秒鐘左右就完成一次日誌切換。這個頻率和我們預期的相差太大。

其實問題到了這裡基本能夠定位明確了。

不過老同學反饋了幾個疑惑的問題，這個任務在每天都會執行，但是不是每天出問題，出問題的時間段經過觀察發現比較規律，基本都是週末的時候出現問題。所以我需要繼續明確下這個問題的潛在原因。

經過排查，這個資料庫裡面沒有發現業務層面的scheduler任務，而且對比相鄰天數同樣時間的awr報告，沒有發現等待的delete語句。

這有幾種情況，一種是確實執行了delete，因為資料量不大，所以delete的結果完全可控，另外一類是這個任務的執行是有視窗時間的，是不是可能在週日的時候啟動了業務層面的任務導致了這個問題。這一點需要在etl的相關配置中確認。

當然一種潛在的影響是資料庫中缺省會在晚上10:00開始一些定時任務，比如統計資訊收集，日誌清理等。這個影響是潛在的，如果存在不規範的delete方式，對於後端自動任務的執行效能是有潛在的隱患的。

所以最後的乙個結論是：

把delete操作改造為truncate操作，這應該是這個問題出現的關鍵解決拌飯

調整redo的大小，如果按照1g的redo來計算，則將近1分鐘切換一次，相比原來的方式要好很多了，況且有了第1個方案的保證，這個的壓力會減少40%左右

檢視週日的定時任務，需要統一檢查，然後禁用掉這列後端任務。

相信這樣一波改進之後，這個問題能夠得到根本性的解決。