點擊上方“IT那活兒”，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！！！

aix主機數(shù)據(jù)庫節(jié)點3因大量高并發(fā)insert語句導(dǎo)致sql積壓，從而短時間內(nèi)消耗大量主機資源，對數(shù)據(jù)庫性能產(chǎn)生了很大影響，嚴(yán)重影響數(shù)據(jù)庫的正常運行，導(dǎo)致節(jié)點3數(shù)據(jù)庫發(fā)生重啟。

1. 20點28分左右，收到節(jié)點3大量sql積壓告警,積壓SQL主要為：9yy1zhgjvfbpj。

2. 登陸環(huán)境核查數(shù)據(jù)庫實例狀態(tài)及實例啟動時間，20點36分確認數(shù)據(jù)庫實例狀態(tài)正常，且實例沒有重啟。當(dāng)即對異常等待事件的sql進行查殺，但是在20點45分時，節(jié)點3發(fā)生重啟。

3. 立即查看數(shù)據(jù)庫相關(guān)日志，并確認數(shù)據(jù)庫日志，發(fā)現(xiàn)節(jié)點3重啟。

4. 核查查看主機日志，并確認無異常報錯信息。

節(jié)點3主機日志：

5. 通過檢查數(shù)據(jù)庫運行狀況，發(fā)現(xiàn)節(jié)點3上有大量sql積壓的等待事件，對應(yīng)等待事件主要為：

enq:us-contention，row cache local行緩存鎖；

enq: IV - contention隊列等待之詢問IV。

• 關(guān)于enq:us-contention官方解釋：這個等待事件有許多脫機撤消段，并且工作負載在短時間內(nèi)開始聯(lián)機許多撤消段。當(dāng)使用具有自動調(diào)整的撤銷保留期的系統(tǒng)管理撤銷時，這可能會導(dǎo)致在DC_ROLLBACK_SEGMENTS 上出現(xiàn)高“閂鎖：行緩存對象”爭用，同時出現(xiàn)高“enq:US-爭用”等待。

• 關(guān)于row cache local官方解釋：該是一個共享池相關(guān)的等待事件。是由于對于字典緩沖的訪問造成的。每一個行緩沖隊列鎖都對應(yīng)一個特定的數(shù)據(jù)字典對象，這被叫做隊列鎖類型，并可以在V$ROWCACHE視圖中找到。在AWR中需要查看Dictionary Cache Stats部分用以確定問題。

• 關(guān)于enq: IV - contention官方解釋：物化視圖（mview）有兩部分：（1）保存數(shù)據(jù)的表，和（2）物化視圖日志。當(dāng)提交mview基表上的DML時，summary對象將失效。這是必要的，因為mview可能需要用于查詢重寫。失效采用IV排隊，直到summary對象在所有節(jié)點上失效為止。如果存在大量摘要無效，則會導(dǎo)致此排隊上的爭用。

6. 通過核查節(jié)點3上sql積壓等待事件對應(yīng)的會話信息，定位到積壓sql對應(yīng)的sql_id。

7. 通過sql定位到對應(yīng)的sql語句。

8. 對故障時間段節(jié)點3分析。

故障時間段每秒產(chǎn)生的redo量相比正常時間段增長了約180%。

故障時間段每秒產(chǎn)生redo量：

正常時間段每秒產(chǎn)生redo量：

經(jīng)核查，發(fā)現(xiàn)等待事件異常最早是20點07分。

通過分析故障時間段哪些SQL占用了資源，發(fā)現(xiàn)其中sql_id為9yy1zhgjvfbpj的語句占用了數(shù)據(jù)庫48.24%的DB TIME，主機資源突降至10%以下，說明數(shù)據(jù)庫大部分時間都在對這條sql進行處理。

9yy1zhgjvfbpj語句執(zhí)行頻次突增截圖：

sql_id為9yy1zhgjvfbpj的語句因高并發(fā)且頻次突增，引發(fā)數(shù)據(jù)庫序列及undo爭用，消耗了大量的數(shù)據(jù)庫資源，導(dǎo)致數(shù)據(jù)庫主機hang住并重啟。

后續(xù)改進措施：對應(yīng)用程序進行優(yōu)化整改，合理調(diào)整sql語句發(fā)起并發(fā)量。