dbms_hprof 是 oracle 19c 中更轻量精准的 pl/sql 性能分析器，支持调用栈、嵌套关系及真实 sql 耗时采集，需 dba 安装 profiler 对象、显式授权并 debug 编译目标过程；其可穿透 sql 引擎层捕获等待事件，而 dbms_profiler 仅记录 pl/sql 控制流耗时。
DBMS_HPROF 是 Oracle 19c 中比 DBMS_PROFILER 更轻量、更精准的 PL/SQL 性能分析器，它能捕获调用栈深度、函数嵌套关系和真实 SQL 执行耗时，且无需显式 FLUSH_DATA —— 数据在会话结束或手动停止时自动落库。
DBMS_HPROF.START_PROFILING 失败的三个硬性前提
启动失败不是配置问题，而是权限与环境缺失的明确信号：
- 必须由 DBA 运行
profload.sql（位于$ORACLE_HOME/rdbms/admin/）安装 profiler 对象，仅 GRANT EXECUTE 权限不够 - 当前用户需被显式授予
EXECUTE ON DBMS_HPROF和SELECT ON plsql_profiler_*（共三张表），角色继承无效 - 目标存储过程必须以
DEBUG模式编译：ALTER PROCEDURE your_proc COMPILE DEBUG，否则行号映射为空或错位
为什么 DBMS_HPROF 能看到 SQL 真实执行时间而 DBMS_PROFILER 不能
DBMS_PROFILER 只记录 PL/SQL 控制流耗时（如赋值、IF 判断、循环），不穿透到 SQL 引擎层；DBMS_HPROF 则在每次 SQL 执行前后打点，把 SELECT INTO、UPDATE、显式游标 OPEN/FETCH 的实际等待和 CPU 时间一并采集。
这意味着：
- 当你在 profiler 报告里看到某行
LINE# 217耗时 92%，先别优化那行 PL/SQL 代码——它可能只是EXECUTE IMMEDIATE v_sql，真正慢的是拼出来的那条动态 SQL - DBMS_HPROF 输出中会出现
SQL*Net message from client或db file sequential read这类等待事件名作为子节点，直接暴露 SQL 层瓶颈 - 必须用
DBMS_HPROF.ANALYZE生成树状报告，不能只查plsql_profiler_data表——后者只存原始采样，无调用上下文
分析报告时必须过滤掉的三类干扰节点
DBMS_HPROF 默认会记录所有 PL/SQL 调用，包括系统包、隐式转换、类型检查等，不剔除就会淹没真实业务热点：
- 排除
STANDARD、DBMS_STANDARD、UTL_*等系统单元：WHERE unit_name NOT IN ('STANDARD','DBMS_STANDARD','UTL_FILE') - 跳过
LINE# = 0的伪节点（表示函数入口，无实际逻辑） - 忽略
TOTAL_TIME （10ms）且 <code>TOTAL_OCCUR 的低频低耗节点——它们对整体响应影响可忽略
真正要盯的是：你自己的包名 + TOTAL_OCCUR > 10 + 单次平均耗时 > 5ms 的组合。
如何从 HPROF 报告反向提取并验证慢 SQL
定位到高耗时 PL/SQL 行后，不能只看代码，必须还原出它触发的真实 SQL：
- 如果是隐式游标（如
SELECT col INTO v_var FROM t WHERE id = p_id），把绑定变量替换成实际值，粘贴到新窗口执行EXPLAIN PLAN FOR SELECT ... - 如果是显式游标，重点检查
CURSOR c IS SELECT ...定义中是否用了函数索引失效写法，例如WHERE UPPER(name) = UPPER(:p_name)或TRUNC(dt) = TRUNC(SYSDATE) - 若 SQL 含动态拼接，用
DBMS_OUTPUT.PUT_LINE(v_sql)在关键位置输出完整语句（注意长度限制），再手工 EXPLAIN
HPROF 报告里显示某行 SQL 耗时 3.2 秒，但 EXPLAIN PLAN 显示走索引、成本仅 5 —— 那大概率是统计信息陈旧或绑定变量窥探导致计划失真，这时得查 DBA_TAB_STATISTICS 的 LAST_ANALYZED 和 STALE_STATS 标志。
