圖片水印為本人在csdn賬號

故障描述

2022 年 7 月 16 號早上 9 點 49 左右，客戶 jsbas 生產庫。客戶反饋應用系統慢並且報超時錯誤； 後續反饋應用使用者無法連線資料庫，其他使用者登入沒問題。

這套 RAC 環境總共 6 個節點，上面執行 5 套資料庫。   出問題的是 jsbas 資料庫， jsbas 資料庫例項執行在節點 3 ， 4 ， 5 ， 6 。其他資料庫都正常。

臨時處理方法

檢查當前等待事件：

檢查發現，大部分都是 library cache lock 等待事件，大概有 1904 個會話。

讓客戶殺掉會話，殺掉之後，隨後又發起 300 多個會話。最後停掉例項 5 解決。

問題詳細診斷過程

檢查會話情況：

2022/7/16 9:14:22 到 2022/7/16 9:15:22  1 分鐘之內活動會話數從 785 增加到 1524 ，增加 739 左右。

檢查 ash 檢視會話情況：

select a.INSTANCE_NUMBER,to_char(a.sample_time, 'yyyy-mm-dd hh24:mi:ss') as "DATE", 
session_id, 
session_serial#, a.USER_ID, sql_id, wait_time,a.P1,a.p1text,
       a.event,a.MACHINE,a.PROGRAM, a.BLOCKING_SESSION,a.BLOCKING_SESSION_SERIAL#,BLOCKING_INST_ID,BLOCKING_SESSION_STATUS
  from dba_hist_active_sess_history a
 where a.sample_time > to_date('2022-07-16 9:00:00', 'yyyy-mm-dd hh24:mi:ss')
   and a.sample_time < to_date('2022-07-16 9:15:00', 'yyyy-mm-dd hh24:mi:ss') order by to_char(a.sample_time, 'yyyy-mm-dd hh24:mi:ss');

從上面可以看出 2022-07-16 09:14:53 這個時間點，大概有 70 個活動會話，而且這些會話基本被其中幾個會話阻塞。 被阻塞的會話等待事件： library cache lock  SQL_ID 為空； 阻塞會話的等待事件： Memory: Reg/Dereg  SQL_ID 為 9zg9qd9bm4spu

   檢查阻塞會話 sql 文字：

完整語句為： update user$ set spare6=DECODE(to_char(:2, 'YYYY-MM-DD'), '0000- 00-00', to_date(NULL), :2) where user#=:1

這個 update 語句的作用是每當使用者會話登入資料庫，會話第一次訪問資料庫的時候記錄使用者的本次登入時間。對應的是 DBA_USERS 檢視裡面的 LAST_LOGIN 欄位。

檢查所有阻塞會話：

從上面可以發現，所有的阻塞會話為上面 6 個會話。

 

檢查 Memory: Reg/Dereg 等待事件：

Mos 上解釋如下：

造成這個等待的原因是 登入風暴，也就是高併發的登入資料庫會導致這個等待事件。

 

檢查 library cache lock 等待事件：

2022-07-16 09:14:53 這個時間點，本次所有的 library cache lock 會話都被 Memory: Reg/Dereg 等待事件會話阻塞，可以判斷這些 library cache lock 會話是登入會話，等待更新登入時間，也就是說上面 70 多個會話都是登入會話。

檢查 MOS(Doc ID 33121934.8) 發現， update user$ 表確實會導致 library cache lock 這個是 oracle bug 。 oracle 12.1.0.2 及以上版本， 23.1 以下都存在這個問題。

 

另外，檢查受影響使用者，除了 JOUR 使用者，還有其他使用者，如下所示：

上面都是應用使用者，由於多個應用使用者的阻塞會話正在執行 update 登入時間，導致後面這些使用者登入會話無法更新底層表的登入時間，所以無法連線資料庫，而其他使用者登入沒問題。

 

總結， 2022-07-16 09:14:53 時間點，應用會話暴增， 70 個使用者會話（主要集中在 jour 使用者）同時登入到資料庫，導致觸發 oracle bug 無法及時更新使用者登入時間。

 

 

解決辦法和建議

1.      建議應用查詢 2022-07-16 09:14:53 時間點，應用會話暴增的原因。

2.      建議從應用角度控制每次併發的會話量。

3.      可以考慮升級到 19.14,19.15 ，然後可以打 oracle bug 補丁（不推薦）。

參考文件

Lots of “ Memory: Reg/Dereg ” waits or high CPU usage by IPC0 background process on Exadata (Doc ID 2832480.1)

Bug 33121934 - Library cache lock / load lock / mutex x during connection storm due to update user$ (Doc ID33121934.8)