Oracle效能排查小案例
Oracle效能排查小案例
原創jeanron1002021-07-23 15:03:10©著作權
昨天一個老同學找我說碰到了資料庫的問題，因為各種雜事一直給耽誤了下，今天做了一個初步的分析。
首先這是一個做統計業務的資料庫，型別可以歸為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%左右
-
檢視週日的定時任務，需要統一檢查，然後禁用掉這列後端任務。
相信這樣一波改進之後，這個問題能夠得到根本性的解決。