大量會話出現resmgr:become active等待

在一個客戶環境的資料庫上發現這個問題。

 

 

當時客戶求助，資料庫狀態不正常，連線到資料庫無法正常操作，而且有時報錯ORA-12537錯誤。

ORA-12537: TNS:connection closed
Cause: "End of file" condition has been reached; partner has disconnected.
Action: None needed; this is an information message.

導致這個錯誤的原因有很多，不好確定問題的原因，於是透過遠端登陸資料庫檢查系統狀態：

SQL> select count(*) from v$session;

  COUNT(*)
----------
       996

SQL> select event, count(*) from v$session group by event having count(*) > 10 order by 2 desc ;

EVENT                       COUNT(*)
------------------------- ----------
resmgr:become active             968
rdbms ipc message                 12

資料庫中會話數接近1000，而根據客戶描述，正常情況下，連線數不到100。更奇怪的是，幾乎所有的會話都在等待resmgr:become active這個事件。

根據事件名稱就可以知道，這是一個資源管理區相關的等待事件，查詢了一下metalink，發現如果系統資源管理區設定為INTERNAL_QUIESCE的狀態，則所有SYS和SYSTEM以外的使用者將處於這個等待事件，而無法進行任何的操作。Metalink文件ID 396970.1描述了這個現象。

但是，當前有幾點和問題描述有所區別。首先，一般在進入WEEKNIGHT_WINDOW 或WEEKEND_WINDOW視窗可能導致這個現象，而使用者出現問題時是下午，因此排除了切換視窗導致資源管理器設定為INTERNAL_QUIESCE的可能性。第二，當發現等待事件為resmgr:become active後，當時就查詢了v$rsrc_plan檢視，結果為空，說明當前系統並沒有設定資源管理策略。

雖然問題的原因並不一定是切換視窗導致的資源管理器設定了資源策略，但是問題顯然和資源管理器有直接的關係。Eygle以前也碰到過類似的現象，根據他的推測，可能是由於連線使用者數過多，從而超過了Oracle內部的某個閾值，導致Oracle自動啟用了資源管理策略。

雖然問題的真正原因還不是很清楚，不過解決這個問題並不複雜，雖然使用者預設resource_manager_plan引數為空，但是Oracle內部仍然可能自動使用資源管理器，因此可以透過隱含引數來禁止資源管理器的啟動：

設定初始化引數"_resource_manager_always_on"=false後，重啟資料庫，這個問題沒有再出現。