在Oracle 19c中怎样通过ASH分析PDB级别的资源消耗-Oracle-PHP中文网

ASH默认不区分PDB，必须显式过滤CON_ID；V$ACTIVE_SESSION_HISTORY数据混存于CDB级，需先查V$PDBS获取目标PDB的CON_ID再过滤；历史分析用DBA_HIST_ACTIVE_SESS_HISTORY（需CDB$ROOT权限）；锁争用排查须关联CON_ID；生成PDB专属ASH报告应使用awrsqrpti.sql而非awrrpti.sql。

在oracle 19c中怎样通过ash分析pdb级别的资源消耗

ASH默认不区分PDB，必须显式过滤`CON_ID`

Oracle 19c的ASH数据（V$ACTIVE_SESSION_HISTORY）物理上存储在CDB级别，所有PDB的采样都混在一起。不加CON_ID条件直接查，看到的是整个CDB的活跃会话，根本分不清哪个SQL来自哪个PDB。你执行SELECT * FROM V$ACTIVE_SESSION_HISTORY WHERE SAMPLE_TIME > SYSDATE - 1/24，结果里CON_ID列全是0或随机值，这不是数据丢了，是没按租户维度筛。

正确做法是：先确认目标PDB的CON_ID，再用它过滤ASH。查法如下：

连接到CDB$ROOT，运行SELECT CON_ID, NAME FROM V$PDBS WHERE NAME = 'YOUR_PDB_NAME';
拿到CON_ID后，在ASH查询中强制加入WHERE CON_ID =
别依赖SESSION_ID或SQL_ID反推PDB——同一个SQL_ID可能在多个PDB里执行，且V$SESSION里的CON_ID和ASH里的不一定实时对齐

`DBA_HIST_ACTIVE_SESS_HISTORY`不是实时数据，但支持PDB归档分析

如果问题发生在几小时前，V$ACTIVE_SESSION_HISTORY内存缓冲区可能已被覆盖（默认保留约1小时），这时得查历史ASH视图DBA_HIST_ACTIVE_SESS_HISTORY。它和AWR快照绑定，每小时自动归档一次，且CON_ID字段完整保留。

注意两点：

该视图需要SELECT_CATALOG_ROLE或DBA权限，普通PDB用户即使连进自己PDB也查不到——必须从CDB$ROOT查
时间范围要对齐快照ID：SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT WHERE BEGIN_INTERVAL_TIME > SYSDATE - 1，再用SNAP_ID关联ASH记录
字段CON_ID、PDB_NAME（19c新增）、SQL_ID、EVENT、SESSION_STATE全都有，可直接做PDB级Top SQL或等待事件聚合

用`ASH`定位PDB内锁争用时，`BLOCKING_SESSION`和`BLOCKING_SESSION_SERIAL#`需配合`CON_ID`一起查

当某个PDB响应变慢，怀疑是内部锁导致，光看EVENT = 'enq: TX - row lock contention'不够。因为阻塞者（BLOCKING_SESSION）可能在另一个PDB里，或者同一PDB但不同容器上下文。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

关键操作是两表关联：

先查出被阻塞会话：SELECT SESSION_ID, SESSION_SERIAL#, CON_ID, BLOCKING_SESSION, BLOCKING_SESSION_SERIAL#, EVENT FROM V$ACTIVE_SESSION_HISTORY WHERE CON_ID = AND EVENT = 'enq: TX - row lock contention' AND ROWNUM
再用阻塞者的SESSION_ID和SESSION_SERIAL#去V$SESSION查详情：SELECT SID, SERIAL#, CON_ID, USERNAME, SQL_ID, STATUS FROM V$SESSION WHERE SID = AND SERIAL# = AND CON_ID IN (, 1)（CON_ID=1代表CDB$ROOT，有些后台锁可能源于根容器）
漏掉CON_ID条件，很可能把阻塞源错判成当前PDB内的会话，实际是CDB级对象（如数据字典表）被锁