查不到存储过程的ASH记录，需先确认其是否真正“活跃”：ASH仅捕获非空闲状态会话，采样粒度为1秒；若存储过程执行总时长过短或处于空闲等待，则可能未被采样。
查不到存储过程的ASH记录？先确认它是否真“活跃”
ASH只捕获处于非空闲状态的会话，且采样粒度为1秒。如果存储过程执行总时长 v$active_session_history里——不是查询姿势错，是根本没被采到。
常见误判场景包括：
- 过程刚
RETURN就退出，或卡在PL/SQL层（如JSON_OBJECT构造、正则REGEXP_LIKE匹配），此时sql_id为NULL，但plsql_entry_object_id仍有效，需加sql_id IS NULL过滤才能看到 - 过程被频繁重编译（如开发环境反复
CREATE OR REPLACE），导致plsql_entry_object_id在采样瞬间未稳定 - 你查的是
dba_hist_active_sess_history，但AWR快照间隔设为1小时，而问题发生在两个快照之间
定位目标过程的object_id和subprogram_id
必须先拿到准确的object_id，否则后续所有过滤都无效。注意区分包内过程和独立过程：
- 独立存储过程：
SELECT object_id FROM all_objects WHERE owner = 'SCOTT' AND object_name = 'MY_PROC' AND object_type = 'PROCEDURE' - 包内过程：需额外确认
subprogram_id，查all_procedures，例如SELECT subprogram_id FROM all_procedures WHERE owner = 'SCOTT' AND object_name = 'MY_PKG' AND procedure_name = 'DO_SOMETHING'（注意序号从1开始） - 若过程在匿名块中被调用（如
BEGIN my_pkg.do_something; END;），top_level_sql_id会指向该匿名块的sql_id，别漏掉这个字段
用plsql_entry_object_id过滤ASH，聚焦内部SQL耗时
ASH本身不记录PL/SQL语句行号，但它把每条内部执行的SQL和等待事件都绑定到入口过程上。关键操作是按sql_id聚合采样次数，并结合session_state和event判断瓶颈类型：
- 执行慢但
session_state = 'ON CPU'且sql_id IS NULL：说明耗时在纯PL/SQL逻辑（如大循环、JSON处理），不是SQL问题 -
sql_id不为空，但event = 'db file sequential read'占比高：对应SQL存在IO密集型操作（如全表扫描、索引回表） - 同一
sql_id在ASH中出现多次，但sql_plan_hash_value不同：说明该SQL被硬解析多次，可能因绑定变量缺失或SQL文本拼接导致 - 用
sample_time做时间窗口限制，避免跨天查询拉低精度，例如WHERE sample_time BETWEEN SYSDATE - 1/1440 AND SYSDATE（查最近1分钟）
关联v$sql看真实执行上下文，避开“同名不同义”陷阱
拿到可疑sql_id后，不能只查v$sql.sql_text就下结论。Oracle中相同sql_id可能对应不同PL/SQL单元里的同名SQL（比如多个包都写了UPDATE t SET x = 1）。必须验证它是否真属于目标过程：
- 查
v$sql中的program_id和program_line#：SELECT program_id, program_line#, sql_text FROM v$sql WHERE sql_id = 'xxx' -
program_id应等于目标过程的object_id；program_line#能指出具体在哪一行触发了这条SQL（如第87行执行了INSERT） - 如果
program_id是其他对象ID，说明该SQL来自调用链上游（比如触发器、另一个包），需顺着top_level_sql_id继续回溯 - 注意
v$sql中SQL可能被截断，完整文本要查v$sqltext_with_newlines并按piece排序拼接
真正难的不是查出哪条SQL耗时长，而是确认它是否在目标过程的业务逻辑路径上——plsql_entry_object_id只保证“调用入口”，不保证“执行路径唯一”。一旦过程被多处调用、或内部有动态SQL拼接，sql_id和program_id的对应关系就容易断裂。这时候得靠top_level_sql_id + 时间戳对齐 + 应用日志交叉验证，而不是单靠ASH一张表。
