plsql_entry_object_id有值但sql_id为空，表明当前正执行纯PL/SQL逻辑（如循环、JSON解析、DBMS_LOCK.SLEEP等）而未发起任何SQL调用，是定位无SQL耗时操作的关键信号。
查 v$active_session_history 时为什么 plsql_entry_object_id 有值但 sql_id 为空？
这是定位纯 PL/SQL 执行（无 SQL 调用）的关键信号。当 plsql_entry_object_id 非空且 sql_id 为 NULL，说明当前采样点正在执行 PL/SQL 逻辑本身——比如大循环、JSON 解析、正则匹配、字符串拼接或 DBMS_LOCK.SLEEP 等操作，没发任何 SQL。
常见错误是只筛 sql_id，结果漏掉所有这类样本；也有人误以为 session_state = 'WAITING' 就一定在等 I/O 或锁，其实 event = 'PL/SQL lock timer' 就是主动休眠。
- 先确认目标对象 ID：
SELECT object_id FROM all_objects WHERE owner = 'SCOTT' AND object_name = 'MY_PROC' AND object_type = 'PROCEDURE' - 再查活跃样本：
SELECT sample_time, session_state, event, p1, p2, p3 FROM v$active_session_history WHERE plsql_entry_object_id = 12345 AND sql_id IS NULL AND sample_time > SYSDATE - INTERVAL '3' MINUTE -
session_state = 'ON CPU'且event为空 → 纯计算瓶颈（如FOR i IN 1..1000000 LOOP ... END LOOP） -
session_state = 'WAITING'且event = 'PL/SQL lock timer'→ 检查是否用了DBMS_LOCK.SLEEP、UTL_HTTP等阻塞调用
DBMS_PROFILER 和 PL/SQL Developer Profiler 哪个更准？
DBMS_PROFILER 是数据库原生工具，能精确到行级耗时和执行次数，适合复现后深度分析；PL/SQL Developer 的 Profiler 图形化强，但依赖客户端连接稳定性，且对匿名块支持弱、不记录递归调用层级。
容易踩的坑：没提前创建 profiler 表（@?/rdbms/admin/profload.sql）、用户缺少 EXECUTE ON DBMS_PROFILER 权限、或忘记在分析前清空旧数据（TRUNCATE TABLE plsql_profiler_data）。
- 启用探查器：
EXEC DBMS_PROFILER.START_PROFILER('my_run'); - 运行目标过程（必须显式调用，不能靠触发器或 JOB 触发）
- 停用并查结果：
EXEC DBMS_PROFILER.STOP_PROFILER;，然后查plsql_profiler_data关联plsql_profiler_units - 注意单位：
total_time是皮秒（10⁻¹² 秒），除以 1000000 得毫秒
为什么 ASH 里找不到正在跑的 PL/SQL 块？
不是代码没跑，而是采样机制限制：ASH 每秒最多采样一次，且只捕获“正在运行”的瞬间。如果 PL/SQL 块执行时间短于 1 秒、或中间有大量 COMMIT/DBMS_OUTPUT.PUT_LINE 导致上下文切换频繁，就可能被跳过。
另一个常见原因是权限或配置问题：v$active_session_history 需要 SELECT_CATALOG_ROLE 或 SELECT ANY DICTIONARY；另外，如果数据库未启用诊断包（diagnostic_dest 未设或磁盘满），ASH 数据会直接丢弃。
- 验证采样是否工作：
SELECT COUNT(*) FROM v$active_session_history WHERE sample_time > SYSDATE - INTERVAL '1' MINUTE，正常应有数百条 - 检查诊断路径：
SHOW PARAMETER diagnostic_dest - 确认时间窗口足够宽，尤其对偶发慢过程，建议查过去 10 分钟而非 1 分钟
优化 PL/SQL 块时最容易忽略的三件事
第一是隐式类型转换：比如把 VARCHAR2 变量传给期望 NUMBER 的函数，会触发每行一次的 TO_NUMBER 调用，循环一万次就是一万次解析开销；第二是反复打开/关闭游标，尤其是带 WHERE 条件的静态 SQL，应改用绑定变量 + OPEN cur FOR sql_str USING bind_var；第三是滥用 DBMS_OUTPUT，它在高并发下会争抢共享池 latch，导致全局性能抖动。
这些点不会出现在执行计划里，也不会报错，但会让同样逻辑的 PL/SQL 在不同负载下表现差异巨大。
- 检查隐式转换：
SELECT sql_text FROM v$sql WHERE sql_text LIKE '%TO_NUMBER%'并关联 PL/SQL 调用栈 - 游标优化：把
OPEN c FOR 'SELECT ... WHERE id = '||v_id改成OPEN c FOR 'SELECT ... WHERE id = :1' USING v_id - 禁用调试输出：
EXEC DBMS_OUTPUT.DISABLE;在正式环境脚本开头加这一句
