不知道是什么时候瞎改,改动了resource_manager相关参数,导致可以以sysdba身份登录,但是不能以normal身份登录!
经过DBA的帮忙,终于找到原因,把相关参数改回来即可!
alter system SET resource_manager_plan = '';
另外,在网上找的一篇类似文章:http://orax.blog.sohu.com/106904414.html
sys可以登陆,其它用户登陆就hang住的处理猪面人心同学在群里说sys用户登陆的时候,可以正常登陆,其它用户登陆的时候就hang,这样的情况经常是由于归档过不出而出现这种状况,由于不清楚具体的情况,于是叫朋友给出v$session_wait的结果,输出的等待事件如下:
- SQL*Net message from client
- jobq slave wait
- Streams AQ: qmn slave idle wait
- resmgr:become active
- SQL*Net message from client
- resmgr:become active
- Streams AQ: waiting for time management or cleanup tasks
- resmgr:become active
- Streams AQ: qmn coordinator idle wait
- resmgr:become active
- SQL*Net message to client
- rdbms ipc message
- rdbms ipc message
- rdbms ipc message
- rdbms ipc message
- smon timer
- rdbms ipc message
- rdbms ipc message
- rdbms ipc message
- rdbms ipc message
- rdbms ipc message
- pmon timer
这些等待事件中除了resmgr:become active 这个等待事件比较可疑外,别的等待事件都是很常见的等待事件,属于idle event,一般不会是引起这个问题的原因,最后把问题定位在resmgr:become active这个等待事件上.
resmgr:become active
这个等待事件的解释
The session is waiting for a resource manager active session slot. This event occurs when the resource manager is enabled and the number of active sessions in the session's current consumer group exceeds the current resource plan's active session limit for the consumer group.
从描述上看这个等待事件的原因和resource manager有关,由于不是很熟悉这东西,自然请google帮忙,在搜索
resmgr:become active过程中找到一个论坛上(http://kr.forums.oracle.com/forums/thread.jspa?threadID=647564),有个人遇到很类似的问题.于是叫朋友查询
select * from V$RSRC_PLAN ;
4840 INTERNAL_QUIESCE TRUE
至此就明白了问题的原因,解决的方法很简单
- alter system SET resource_manager_plan = '';
- INTERNAL_QUIESCE:
- INTERNAL_QUIESCE - freezes all sessions out (by setting max number of sessions to 0) except for SYS_GROUP
- 起用了INTERNAL_QUIESCE后只允许SYS_GROUP中的user登陆 SQL> show parameter plan
- NAME TYPE VALUE
- ------------------------------------ ----------- ------------------------------
- resource_manager_plan string INTERNAL_QUIESCE
转载于:https://blog.51cto.com/huqianhao/956978