ASH能定位PGA溢出引发的挂起，因pga_allocated是采样快照、写入DBA_HIST_ACTIVE_SESS_HISTORY后可保留8天，而v$session.pga_used_mem为实时值、会话断开即清零；需用动态时间窗口查历史视图，结合direct path write temp等等待事件及MMNL进程状态综合判断。
ASH 能定位 PGA 溢出引发的挂起，但必须用 pga_allocated 字段 + 历史视图 + 时间窗口精准回溯，不能查 v$session 或 v$process。
为什么 v$session.pga_used_mem 查不到溢出会话
会话挂起时若已断开或被 PMON 清理，v$session 和 v$process 中的 pga_used_mem 就清零了；而真正反映“内存申请峰值”的是 ASH 采样里的 pga_allocated —— 它是快照值，写入 DBA_HIST_ACTIVE_SESS_HISTORY 后可长期保留（默认 8 天）。常见错误是直接查 v$session 找“当前最大 PGA”，结果一无所获。
-
pga_allocated单位是字节，v$process.pga_used_mem也是字节，但v$session_workarea_active.actual_mem_used是 KB，混用必错 -
pga_allocated包含已向 OS 申请但尚未释放的内存（如 PL/SQL 变量、大集合未显式DELETE），比实际驻留更“激进”，更适合捕捉泄漏点 - 挂起往往发生在 PGA 分配瞬间（比如排序/哈希连接触发大量分配），此时会话可能还没来得及出现在
v$session的 ACTIVE 列表里
查 DBA_HIST_ACTIVE_SESS_HISTORY 的正确姿势
目标不是找“当前”，而是还原挂起发生前 5–15 分钟的 PGA 分配峰值。关键在时间范围、聚合粒度和过滤条件：
- 时间必须用动态表达式：
SAMPLE_TIME BETWEEN SYSDATE - INTERVAL '10' MINUTE AND SYSDATE，避免硬编码字符串导致时区/NLS 失效 - 必须加
WHERE pga_allocated IS NOT NULL，否则大量空值干扰排序 - 按
sql_id+instance_number分组后取MAX(pga_allocated)，再除以 1024/1024 得 MB - RAC 环境务必用
DBA_HIST_ACTIVE_SESS_HISTORY（它自动合并所有实例），别用gv$active_session_history—— 后者只存内存，挂起时刻可能已被覆盖
示例查询：
SELECT sql_id, instance_number, ROUND(MAX(pga_allocated)/1024/1024) pga_mb FROM dba_hist_active_sess_history WHERE sample_time > SYSDATE - INTERVAL '12' MINUTE AND pga_allocated > 500*1024*1024 -- 先筛掉小内存干扰 GROUP BY sql_id, instance_number ORDER BY pga_mb DESC FETCH FIRST 5 ROWS ONLY;
结合等待事件确认是否真为 PGA 触发挂起
单看 PGA 高只是嫌疑，要坐实需匹配挂起时段的等待特征。PGA 溢出常伴随两类典型等待：
-
direct path write temp：说明排序/哈希溢出到临时表空间，但 temp 表空间本身又慢或满（见ORA-1652），形成阻塞链 -
latch: shared pool或library cache lock：大量硬解析或 SQL 共享池争用，间接推高 PGA（每个 cursor 解析都吃内存）
执行以下联合查询验证：
SELECT sql_id, event, COUNT(*) cnt, ROUND(AVG(pga_allocated)/1024/1024) avg_pga_mb
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN TO_TIMESTAMP('2026/10/27 18:30', 'yyyy/mm/dd hh24:mi')
AND TO_TIMESTAMP('2026/10/27 18:45', 'yyyy/mm/dd hh24:mi')
AND event IN ('direct path write temp', 'latch: shared pool', 'library cache lock')
AND pga_allocated > 200*1024*1024
GROUP BY sql_id, event
ORDER BY cnt DESC;
如果某 sql_id 同时高频出现高 pga_allocated 和上述任一等待，基本可判定为根因。
容易被忽略的缓冲区陷阱：_ash_size 不足导致采样丢失
ASH 数据先存在 SGA 的循环缓冲区，再由 MMNL 进程刷入磁盘。若挂起期间 MMNL 自身被阻塞（比如也卡在 latch: shared pool），则缓冲区满后旧样本被覆盖，DBA_HIST_ACTIVE_SESS_HISTORY 里就缺数据 —— 此时你查不到任何高 PGA 样本，不是没发生，是丢了。
- 检查
_ash_size是否合理：8 核机器默认约 144MB，但高并发场景建议手动调大（如设为 512MB） - 查
MMNL状态：SELECT * FROM v$process WHERE program LIKE '%MMNL%'，确认其PADDR是否出现在v$session的blocking_session列中 - 若发现
MMNL阻塞，优先分析其等待事件，而非继续深挖应用 SQL —— 这是诊断链的上游断点
真正难的不是写 SQL，是在 PGA 溢出、MMNL 阻塞、temp 表空间争用三者交织时，分清哪个是因、哪个是果。时间线对齐比字段值更重要。
