被resource manager挂起的会话在v$active_session_history中表现为waiting状态、等待事件为resmgr: become active或resmgr: waiting for resource plan，需结合resource_manager_plan启用状态、active_session_pool_p1配置及当前活跃会话数综合判断。
查 v$active_session_history 中被 resource manager 挂起的会话
oracle 的资源管理器（resource manager）在启用并配置了 active_session_pool_p1 等限制后，会主动挂起超出配额的会话——这类挂起不会报错，也不会阻塞在锁或 latch 上，而是静默停留在 waiting 状态，等待资源池释放 slot。关键识别点是：等待事件为 resmgr: become active 或 resmgr: waiting for resource plan，且 session_state = 'waiting'。
执行以下查询可快速定位近期被挂起的会话：
SELECT sample_time,
session_id,
session_serial#,
program,
module,
sql_id,
event,
p1text, p1,
blocking_session,
sql_exec_id
FROM v$active_session_history
WHERE event IN ('resmgr: become active', 'resmgr: waiting for resource plan')
AND sample_time > SYSDATE - 1/24 -- 近1小时
ORDER BY sample_time DESC;
注意：V$ACTIVE_SESSION_HISTORY 默认只保留约 1 小时（取决于 AWR 采样频率和内存大小），若问题发生较早，需结合 AWR 报告或 DBA_HIST_ACTIVE_SESS_HISTORY 查询历史快照。
确认资源管理器是否启用及当前 plan
挂起行为必须依赖启用中的资源计划。如果 resource_manager_plan 参数为空或为 ''，即使定义了 plan，也不会生效。
检查方式：
- 运行
SHOW PARAMETER resource_manager_plan—— 值必须是非空字符串（如DAYTIME_PLAN） - 查询
SELECT name, is_top_plan, status FROM dba_rsrc_plans WHERE status = 'ACTIVE'，确认 plan 已激活且为 top-level - 用
SELECT * FROM dba_rsrc_consumer_groups核对 consumer group 是否配置了active_session_pool_p1（这是触发挂起的核心参数）
常见误判：看到 DBA_RSRC_PLANS 里有 plan 就认为已启用，但实际可能只是定义未激活，或被 ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '' 显式关闭。
区分 resmgr: become active 和真实阻塞
这个等待事件常被误读为“正在尝试获取资源”，但它本质是「已排队、正等待轮到自己成为 active」。它不表示资源争用（比如 CPU 或 I/O 不足），而纯属资源管理器的准入控制逻辑。
关键判断依据：
- 若
blocking_session为 NULL，且event是resmgr: become active→ 典型挂起，非故障 - 若同时存在
enq: KO - fast object checkpoint或read by other session等真实 I/O 等待 → 需单独排查底层性能瓶颈，与 Resource Manager 无关 -
p1值含义：对resmgr: become active，p1是 consumer group ID；可用SELECT consumer_group_id, consumer_group FROM dba_rsrc_consumer_groups反查具体组名
验证挂起是否由 active_session_pool_p1 触发
该参数设定了 consumer group 允许并发 active session 的上限。一旦超限，新会话就会卡在 resmgr: become active，直到已有会话退出 active 状态（如提交、回滚、断开或被 kill）。
检查步骤：
- 查当前 consumer group 配置：
SELECT consumer_group, active_session_pool_p1, parallel_degree_limit_p1 FROM dba_rsrc_plan_directives WHERE plan = (SELECT value FROM v$parameter WHERE name = 'resource_manager_plan') - 统计当前该 group 下 active session 数：
SELECT COUNT(*) FROM v$session WHERE resource_consumer_group = 'YOUR_GROUP_NAME' AND status = 'ACTIVE' - 若统计数 ≥
active_session_pool_p1，且存在大量resmgr: become active等待 → 基本锁定根因
注意：active_session_pool_p1 对后台进程（如 DBWR、LGWR）无效，仅作用于前台用户会话；另外，它不计算 INACTIVE 状态的连接（如空闲连接池连接），只管真正执行 SQL 的活跃会话。
最易忽略的一点：挂起会话在 V$SESSION 中仍显示 STATUS = 'ACTIVE'，但其 STATE = 'WAITING' 且 EVENT 明确指向 resmgr。很多人只扫 V$SESSION 的 STATUS 字段就误判为“还在跑”，其实早已被资源管理器冻结——得看 STATE 和 EVENT 才算真正看清状态。
