oracle一次卡頓案例(四)
圖片水印為本人在csdn賬號
故障描述
2023年09月14號 9:33左右,客戶反饋his資料庫可能存在問題,當時資料庫可以使用,應用比較緩慢。讓檢查資料庫是否存在問題。
排查過程中,業務那邊反饋問題從8點左右就開始,應用頁面報錯如下圖所示:
原因分析-ORA-30006
應用頁面報ORA-30006錯誤,檢查早上8:00左右會話情況,會話執行下面的語句被阻塞的比較多。
SELECT * FROM COM_SEQUENCE t WHERE T.ID = :1 FOR UPDATE WAIT 5
只要持有這條WHERE T.ID = :1 記錄的會話事務沒有結束,那麼其他會話執行上面的語句,等待5秒,就會報這個錯。
這個很明顯是業務裡面的事務沒有及時提交導致的。
原因分析-row cache lock
檢查8點左右的業務會話,發現會話不多,同一個時間點只有1,2個活動的業務會話。
檢查當時的等待事件結果如下:
檢查row cache lock等待事件:
Select a.*
from ash_temp2 a
where a.sample_time > to_date('2023-09-14 08:00:00', 'yyyy-mm-dd hh24:mi:ss')
and a.sample_time < to_date('2023-09-14 09:30:00', 'yyyy-mm-dd hh24:mi:ss')
and SESSION_TYPE<>'BACKGROUND' and a.WAIT_CLASS<>'Idle'
and event='row cache lock'
order by a.sample_time;
檢查發現,row cache lock等待事件的P1引數為13。
檢查爭用的型別,發現都是序列的爭用:
SQL> select parameter from v$rowcache where cache#=13;
PARAMETER
--------------------------------
dc_sequences;
檢查sql發現,主要集中在下面的sql:
9zydhubnyc1v0:
SELECT SEQ_LSH.NEXTVAL FROM DUAL WHERE :1 = :2
8mzhcp786symv:
SELECT B32011400642602056X.Nextval FROM DUAL
dayjkkmjpuvww:
SELECT B320114001426020535.Nextval FROM DUAL
……
檢查序列情況:
發現cache_size為0,這個數值過小,在高併發的環境下,很容易造成效能問題,建議調整這些序列尤其是SEQ_LSH 序列的cache size。
應用人員在10點左右發現資料庫不可用,無法連線。在伺服器上面透過sqlplus也無法登入資料庫。
臨時的解決方法,殺掉所有的業務會話解決。
事後檢查當時的等待事件:
關於latch: shared pool等待事件:oracle為了分配共享池,多個會話執行sql解析需要分配到chunk時,為了獲得的shared pool latch發生爭用,常見於併發會話比較高或者硬解析比較多的場景,也就是說在獲得shared poollatch過程中發生爭用,則等待latch: shared pool事件。
檢查會話發現,這些會話執行的sql同row cache lock等待事件會話的sql基本一樣,也就是說,一個會話交替出現,所以這個2個等待事件可以看成是一個問題。
關於library cache: mutex X:在 library cache 中有許多記憶體結構需要 library cache: mutex X 的保護,每當 library cache mutex由會話以獨佔模式保持並且其他會話需要等待它被釋放時,就會出現此等待事件。
檢查會話發現,這些會話執行的sql並沒有高版本的情況而且資料庫整體硬解析不高,所以可以判斷這些會話沒有問題。而且這個等待事件相關的bug也比較多,可以作為後面的分析方向。
解決辦法和建議
1. COM_SEQUENCE表相關的業務,建議及時進行提交,可以解決應用頁面ORA-30006的問題。
2. 要徹底解決row cache lock異常等待的問題,建議調整這些序列的cache size,建議從0調整到1000-5000,如果資料庫重啟或者遇到異常,cache可能會丟失,建議業務進行評估。
3. 檢查過程中發現,發現shared pool 設定不太合理,建議調大共享池大小,在現有的基礎上增加至少10G。
4. 伺服器剩餘的記憶體比較小,叢集上面還有一個例項mdm,這個例項佔用的記憶體比較多,如果不需要可以考慮關閉。
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/69980685/viewspace-3003371/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- oracle一次卡頓案例(三)Oracle
- oracle一次卡頓案例(六)-latch freeOracle
- 一次Oracle診斷案例-Spfile案例Oracle
- Oracle SQL*Loader使用案例(四)OracleSQL
- 一次ORACLE IO效能診斷案例Oracle
- 一次Oracle診斷案例-SGA與SwapOracle
- Oracle效能優化-SQL優化(案例四)Oracle優化SQL
- oracle資料庫卡頓Oracle資料庫
- Oracle某行系統SQL最佳化(案例四)OracleSQL
- RMAN備份恢復典型案例——資料庫卡頓資料庫
- 一次HIS系統卡頓原因排查過程分享
- LGWR寫操作會導致效能全域性卡頓案例分析
- Oracle 11gRac 測試案例(四)叢集程式錯誤Oracle
- 從一次 FULL GC 卡頓談對服務的影響GC
- 一次expdp/impdp遷移案例
- 一次成功的優化案例優化
- 【MySQL】死鎖案例之四MySql
- SQL Server一次SQL調優案例SQLServer
- 記一次PHP最佳化案例PHP
- ORACLE診斷案例Oracle
- Oracle stream案例分享Oracle
- 記一次前端效能優化的案例前端優化
- GO 陣列操作四個小案例Go陣列
- Oracle案例12——NBU Oracle恢復Oracle
- android檢測卡頓問題,recycleview卡頓AndroidView
- 一次生產的 JVM 優化案例JVM優化
- oracle SPA 效能分析案例Oracle
- 記一次 gocode 在高版本 Go 高耗 CPU 導致的 LiteIDE 卡頓GoIDE
- 一次Web端大量圖片同時載入卡頓問題的優化之旅Web優化
- 記一次 hosts 檔案配置錯誤導致應用卡頓的奇葩問題
- Oracle優化案例-從Exadata遷移到國產一體機一般方法探究(四)Oracle優化
- 優化動畫卡頓:卡頓原因分析及優化方案優化動畫
- 一次elasticsearch 查詢瞬間超時案例分析Elasticsearch
- 一次系統延遲性最佳化案例
- 記一次遠端協助的排錯案例
- 案例四:Shell指令碼生成隨機密碼指令碼隨機密碼
- 搶紅包案例分析以及程式碼實現(四)
- Oracle優化案例-(三十四)Oracle優化