【ASK_ORACLE】因process用盡導致的rac重啟的解決方法

說明

上週末一個重要系統出現了問題導致rac重啟，影響了業務，因此記錄一下解決過程。

環境

搭建平臺：VMware Workstation

OS：RHEL 6.10

Grid&DB：Oracle 11.2.0.4

 

問題描述

上週末下午資料庫的會話數突增，導致資料庫節點一程式數滿了，應用新的會話連線節點1報錯，alert日誌中出現大量的ORA-00020報錯，直到30分鐘後節點一例項重啟，隨後資料庫恢復正常。在這期間影響了多筆重要業務。

 

分析過程

alert日誌顯示最大程式數用盡，出現ORA-00020的反覆報錯，此時資料庫已經發生阻塞，導致節點一例項process用盡。

 

ASH發現16:21開始1#會話突增,16:22開始2#例項突增：可以看出是1#節點先出現問題，隨後導致2#例項的會話數突增。

 

發現16:21:02開始出現等待enq: US – contention，16:21:12  1#出現12個ens: US等待，隨後出現enq: SV -contention:

注：

enq: US – contention是事務出現undo segment不夠時需要申請新的undo segment產生的阻塞

enq: SV – contention是獲取sequence number而產生的阻塞

 

檢視對應的SQL ID發現都是DML操作：

檢視awr報告：

1. 發現相關SQL和兩個sequence有關，於是檢視這些sequence的定義後發現了兩個問題：

（1）有order關鍵字，會導致RAC環境操作進行2個節點的同步處理

（2）Cache過小

因此enq: US – contention和enq: SV – contention等待是相關關聯的，enq: US 阻塞會導致包含sequence nextval的DML無法提交，導致sequence更新cache失敗；而enq: SV -contention阻塞也可能導致sequence更新慢，DML操作緩慢。

 

2. AWR發現故障之前最大併發事務100左右，因此ONLINE的undo segment可能在100左右，但是故障時兩個問題SQL的確出現了接近200的併發session，並且二節點當時也有少量併發sql。同時檢視兩個節點的歷史最大會話數在2千多

 

綜上分析，本次故障原因是突增的併發DML語句，導致online undo segment不夠，當online擴充套件undo段時產生阻塞，並且相關問題SQL的sequence使用order模式，會導致順序同步爭用，跨節點操作更嚴重。

 

解決方法

1、按關閉自動undo管理，並設定足夠的online回滾段:

alter system set "_rollback_segment_count"=3000;

alter system set "_undo_autotune"=FALSE;

2、 修改sequence cache到10000，取消order，減少資料字典更新頻率及同步：

alter sequence XXX1_SEQ_S cache 10000 noorder;

alter sequence XXX2_SEQ_S cache 10000 noorder;

3、為避免跨例項同步，使應用連線同一個例項