Oracle中為何大量會話出現resmgr:become active等待

來源:互聯網
上載者:User

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

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

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.