在一個客戶環境的資料庫上發現這個問題。
當時客戶求助,資料庫狀態不正常,串連到資料庫無法正常操作,而且有時報錯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後,重啟資料庫,這個問題沒有再出現。