Oracle 12c中PDB间CPU资源争用不能靠ASH直接识别，因GV$ACTIVE_SESSION_HISTORY不含CON_ID字段，无法关联PDB；需结合GV$RSRC_SESSION_INFO（含CON_ID、CPU_WAIT_TIME、CURRENT_CONSUMER_GROUP）与GV$SESSION跨视图关联定位，或依赖AWR中DBA_HIST_RSRC_CONSUMER_GROUP的快照级PDB资源统计。
Oracle 12c中PDB间CPU资源争用不能靠ASH直接识别——v$active_session_history不记录PDB归属信息，CON_ID字段在ASH里根本不存在；真正能定位PDB级CPU挤压的，是结合gv$rsrc_session_info和gv$active_session_history做跨视图关联。
为什么ASH里查不到PDB名称或CON_ID
ASH视图设计上只保留会话级运行时状态（如session_id、sql_id、session_state），但刻意剥离了容器上下文：CON_ID不出现在v$active_session_history或gv$active_session_history的列定义中。这意味着你无论怎么JOIN DBA_PDBS或WHERE CON_NAME = 'PDB1'，都会失败——字段压根不存在。
- 所有基于
CON_ID过滤ASH的尝试都无效，包括SELECT * FROM gv$active_session_history WHERE CON_ID = 3 -
gv$active_session_history的inst_id是RAC实例号，不是PDB编号；别混淆inst_id和con_id - 想从ASH反推PDB？唯一可行路径是先通过
session_id和inst_id关联gv$session，再查其con_id，但该关联仅在采样时刻会话仍活跃时才可靠
如何用gv$rsrc_session_info定位PDB级CPU等待
gv$rsrc_session_info是Resource Manager在CDB层暴露的实时PDB资源视图，它包含con_id、current_consumer_group、wait_time和cpu_wait_time——这才是诊断PDB CPU争用的黄金字段。
-
CPU_WAIT_TIME单位是厘秒（centiseconds），值>10000（即100秒）说明该PDB内会话已因资源限制排队等待CPU - 重点看
CURRENT_CONSUMER_GROUP是否为OTHER_GROUPS：这是默认兜底组，配额仅1% CPU且无并行权限 - 执行
SELECT con_id, name FROM v$pdbs确认目标PDB的con_id，再查SELECT * FROM gv$rsrc_session_info WHERE con_id = &con_id AND cpu_wait_time > 0 - RAC环境下必须用
gv$前缀，否则只看到本实例的PDB会话
怎样把ASH的高CPU SQL和具体PDB绑定起来
核心思路：不强求ASH带PDB字段，而是用时间窗口+会话ID双锚点，在ASH采样期内捕获的SQL，与同一时刻gv$session中活跃会话的con_id做瞬时关联。
- 先查出最近5分钟高CPU的
sql_id：SELECT sql_id, COUNT(*) samples FROM gv$active_session_history WHERE session_state = 'ON CPU' AND sample_time > SYSDATE - 5/1440 GROUP BY sql_id ORDER BY samples DESC FETCH FIRST 10 ROWS ONLY - 对每个高采样
sql_id，执行：SELECT s.con_id, p.name pdb_name, COUNT(*) FROM gv$session s JOIN v$pdbs p ON s.con_id = p.con_id WHERE s.sql_id = '&sql_id' AND s.status = 'ACTIVE' GROUP BY s.con_id, p.name - 注意
gv$session中con_id = 1表示CDB$ROOT，con_id > 1才是PDB；若查不到结果，说明该SQL执行完后会话已退出，需结合dba_hist_active_sess_history回溯（需AWR权限） - 别依赖
v$sql的con_id字段——它不存在；v$sql是共享池级视图，无容器维度
为什么AWR报告里的“Resource Limit Statistics”比ASH更适配PDB CPU分析
AWR快照在生成时已固化PDB上下文：DBA_HIST_RSRC_CONSUMER_GROUP表明确记录每个PDB在每个快照周期内的cpu_wait_time、active_sessions_limit和实际使用率，而ASH是动态流式采样，无法聚合容器级统计。
- AWR中“Resource Limit Statistics”小节直接显示
PDB1的CPU_WAIT_TIME是否持续>90%阈值，这是ASH永远给不了的结论性指标 -
SELECT * FROM DBA_HIST_RSRC_CONSUMER_GROUP WHERE snap_id IN (SELECT MAX(snap_id) FROM dba_hist_snapshot) AND con_id = &con_id可快速定位当前快照下PDB资源消耗峰值 - ASH能告诉你“哪条SQL此刻吃CPU”，但AWR才能回答“这个PDB过去一小时是不是一直被限速”——二者定位层级不同，不可替代
最易被忽略的一点：Resource Manager对PDB的CPU限制是“软限”，不会触发错误或等待事件，只会让会话在resmgr:cpu quantum事件上排队；ASH里看不到这个事件，它只出现在v$session_event或AWR的“Wait Events”部分。
