当时客户求助，数据库状态不正常，连接到数据库无法正常操作，而且有时报错ORA-12537错误。ORA-12537: TNS:connection closedCau
在一个客户环境的数据库上发现这个问题。
当时客户求助，数据库状态不正常，连接到数据库无法正常操作，而且有时报错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后，重启数据库，这个问题没有再出现。