dbms_profiler并非唯一工具，且必须完成三步强制前置动作：sys用户安装包、目标用户建表并赋权、同一会话执行start/业务/stop；缺一不可，否则报ora-06528或ora-04043。
DBMS_PROFILER 是唯一能定位到 PL/SQL 每行代码耗时的工具，但默认不启用、不建表、不赋权就直接调用 START_PROFILER，必然报 ORA-06528 或 ORA-04043——这不是配置问题，是漏掉了三步强制前置动作。
确认 DBMS_PROFILER 包是否已安装（SYS 用户）
很多人跳过这步，直接用普通用户执行 DESC dbms_profiler，结果报错就以为“没这个包”。实际必须用 SYS AS SYSDBA 连接后验证：
- 若返回
ORA-04043: object dbms_profiler does not exist，说明未安装，需运行@?/rdbms/admin/profload.sql - 该脚本只创建包和同义词，不建任何表；且只能由
SYS执行，普通用户执行会失败 - 装完立刻
DESC dbms_profiler确认存在，别信“别人说装过了”
用目标用户建 profiler 表（非 SYS）
三张核心表 PLSQL_PROFILER_RUNS、PLSQL_PROFILER_UNITS、PLSQL_PROFILER_DATA 必须由“将要运行被测代码”的用户自己创建：
- 用待测代码所属用户（如
SCOTT）登录，执行@?/rdbms/admin/proftab.sql - 如果报
ORA-01031: insufficient privileges，不是缺 EXECUTE 权限，而是缺CREATE TABLE——需SYS先授此权限 - 建完立刻查
USER_TABLES，确认三张表真实存在；否则后续STOP_PROFILER后查不到任何数据
同 session 执行 start / 业务代码 / stop（关键！）
跨 session 调用 START_PROFILER 和 STOP_PROFILER 是最常踩的坑，会导致数据写入失败或完全丢失：
- 必须在同一个数据库会话中完成：先
START_PROFILER→ 再执行你要测的存储过程或匿名块 → 最后STOP_PROFILER -
START_PROFILER返回的run_number是后续查数据的唯一入口，建议用变量捕获，别硬编码字符串注释 - 如果被测代码含 DML，务必
COMMIT；否则事务未结束，PLSQL_PROFILER_DATA表可能查不到记录 -
DBMS_PROFILER.FLUSH_DATA只在异常中断时手动刷缓存用，正常流程不需要调用
查数据时注意单位换算和关联逻辑
原始数据单位是纳秒，直接看数字毫无意义；且必须把源码行号、执行次数、耗时三者对齐才能定位瓶颈：
- 查询语句必须关联
ALL_SOURCE（获取源码文本）和PLSQL_PROFILER_DATA（获取耗时），靠unit_number+line+runid三重匹配 - 时间字段如
total_time单位是纳秒，除以1000000才得毫秒，不换算根本看不出哪行慢 - 重点关注
total_occur高但total_time更高的行——可能是低效循环或未走索引的 SQL
真正卡住人的从来不是 profiler 本身，而是三张表建在哪、谁建的、什么时候 commit、runid 怎么传——这些细节一旦错位，整个分析就归零。别假设环境干净，每一步都亲手验证。
