ORA-04036报错后应通过ASH定位PGA占用最高的SQL_ID：按instance_number、sample_time、sql_id分组聚合pga_allocated最大值并转MB，避免累加虚高，需确保时间精度、权限及RAC多实例覆盖。
怎么从ASH里揪出PGA占用最高的SQL_ID
ora-04036报错后，最急的是定位哪条sql在“狂吃”pga。ash（dba_hist_active_sess_history）是唯一能回溯历史会话级内存分配的来源——它每秒采样一次，字段pga_allocated记录了该采样点该会话已分配的pga字节数。
直接查单次峰值容易误判，因为一条SQL可能只在某个sample_time瞬间飙高；更可靠的做法是按SQL_ID聚合其在时间窗口内各采样点的PGA分配最大值：
- 用
ROUND(SUM(NVL(pga_allocated, 0))/1024/1024)把字节转MB，避免小数干扰排序 - 必须
GROUP BY instance_number, sample_time, sql_id再外层MAX(pga_sum_mb)，否则会把同一SQL在不同采样点的值累加，结果虚高 - 时间范围务必用
TO_TIMESTAMP('&begin_timestamp', 'yyyy/mm/dd hh24:mi')，别漏掉hh24:mi精度，否则可能跨过关键采样点
执行以下语句即可拿到Top 10：
select * from (
select instance_number, sql_id, max(pga_sum_mb) pga_max
from (
select instance_number, sample_time, sql_id,
round(sum(nvl(pga_allocated, 0))/1024/1024) pga_sum_mb
from dba_hist_active_sess_history
where sample_time between to_timestamp('2026/03/22 14:00', 'yyyy/mm/dd hh24:mi')
and to_timestamp('2026/03/22 15:00', 'yyyy/mm/dd hh24:mi')
group by instance_number, sample_time, sql_id
)
group by instance_number, sql_id
order by pga_max desc
)
where rownum <= 10;为什么pga_allocated比V$PROCESS.pga_used_mem更适合回溯
V$PROCESS.pga_used_mem反映的是当前实时值，会话一终止就清零，根本无法用于事后分析；而ASH里的pga_allocated是采样快照，哪怕会话已断开、数据库重启，只要AWR保留期够长（默认8天），数据仍在DBA_HIST_*中。
注意两个关键区别：
-
pga_allocated包含所有已向OS申请但未必“正在用”的内存（如PL/SQL变量分配后未释放），而pga_used_mem更接近真实驻留量 - ASH中
pga_allocated单位是字节，V$PROCESS里是字节，但V$SESSION_WORKAREA_ACTIVE.actual_mem_used却是KB——单位不统一，混用必出错 - 如果目标时段ASH被purge过（比如
dbms_workload_repository.modify_snapshot_settings调小了保留天数），那再准的SQL也查不到数据
查到SQL_ID后，怎么确认是不是真凶
光有SQL_ID不够，得验证它是否真的触发了PGA超限。重点看三处交叉证据：
- 去告警日志（alert.log）搜
PGA memory limit exceeded，找到报错时间点，再拿这个时间去ASH里查对应sample_time附近的sql_id，看是否匹配 - 用
DBA_HIST_SQLSTAT查该SQL_ID的max_pga_allocated字段，这是Oracle自己统计的该SQL历史最大PGA使用量，和ASH结果应趋势一致 - 查
V$SQL_WORKAREA_HISTOGRAM里该SQL涉及的操作类型（如HASH JOIN或SORT），若multi_pass_executions > 0，说明它确实因PGA不足被迫写临时段，是典型根因
如果三者时间、SQL_ID、操作类型都对得上，基本可以锁死。
容易忽略的采样偏差和权限坑
ASH不是全量记录：它默认只采样处于非空闲等待（session_state = 'WAITING'且wait_class != 'Idle'）或正在CPU上运行（session_state = 'ON CPU'）的会话。如果某条SQL大部分时间在“软解析”或“PL/SQL执行”中消耗PGA，但没触发明显等待或CPU飙升，它可能压根不会出现在ASH里。
权限和对象可见性也常卡人：
- 必须有
SELECT_CATALOG_ROLE或直接授予SELECT ON DBA_HIST_ACTIVE_SESS_HISTORY，仅SELECT ANY DICTIONARY不够 - 查询时若没指定
instance_number，RAC环境可能只返回当前实例数据，漏掉其他节点的“内存巨鲸” -
pga_allocated在11g中叫pga_allocated，但在10g里字段名是pga_alloc_mem——版本低还硬套12c脚本，结果全为NULL
真要挖深，得结合trace文件里的workarea: … size=…堆栈，但那是另一层功夫了。
