Oracle 12c 默认已安装 DBMS_PROFILER 包但未启用，需 SYS 运行 profload.sql 加载包体、专用用户运行 proftab.sql 创建表及序列，并向开发用户授予 EXECUTE 权限和 profiler 表的 DML 权限。
DBMS_PROFILER 在 Oracle 12c 中是否默认可用
Oracle 12c 默认已安装 DBMS_PROFILER 包，但不默认启用——它需要手动加载表结构和授权。执行 DESC DBMS_PROFILER 能看到包存在，不代表 profiler 表（PLSQL_PROFILER_RUNS 等）已建好，更不代表你有权限写入。静默失败是常见现象：调用 START_PROFILER 成功返回，但查不到数据，大概率是表没建或权限缺失。
必须完成的三步初始化（缺一不可）
以下操作需按顺序、在对应用户下执行：
- 以
SYS用户运行@?/rdbms/admin/profload.sql（确认包体加载成功，末尾提示SYS.DBMS_PROFILER successfully loaded） - 创建专用 profiler 用户（如
PROFILER），并用该用户执行@?/rdbms/admin/proftab.sql（此脚本建PLSQL_PROFILER_RUNS、PLSQL_PROFILER_UNITS、PLSQL_PROFILER_DATA和序列PLSQL_PROFILER_RUNNUMBER） - 给目标开发用户（如
SCOTT）授权：GRANT EXECUTE ON SYS.DBMS_PROFILER TO SCOTT；同时授权查询 profiler 表：GRANT SELECT, INSERT, UPDATE, DELETE ON PROFILER.PLSQL_PROFILER_DATA TO SCOTT等（或通过同义词+PUBLIC 授权）
执行 profiling 的会话约束很严格
所有操作必须在同一个数据库会话中完成，否则数据不落库：
-
DBMS_PROFILER.START_PROFILER启动后，立刻执行目标存储过程（不能断开连接、不能换会话） - 存储过程执行完，**立即**调用
DBMS_PROFILER.STOP_PROFILER，再紧跟着调用DBMS_PROFILER.FLUSH_DATA（FLUSH_DATA不是可选步骤，它是把内存缓冲数据刷入表的关键动作） - 若中间发生异常或会话中断，
STOP_PROFILER未执行，则 profiler 数据滞留在 PGA，下次启动新 run 时会被覆盖，查不到历史记录
看懂 profiler 输出里真正要盯的两列
查 PLSQL_PROFILER_DATA 时，别只排序 TOTAL_TIME。关键要看组合指标：
-
TOTAL_OCCUR > 1且TOTAL_TIME / TOTAL_OCCUR > 0.01（单位：微秒）的行——说明这行代码高频且单次不快，比如循环内重复调用函数、隐式类型转换、低效赋值 -
TOTAL_OCCUR = 1但TOTAL_TIME极高（如 >5e6 微秒 ≈ 5 秒）的行——大概率是某条 SQL 卡住了，但它本身只是SELECT INTO或UPDATE语句，真瓶颈在背后执行计划、I/O 等待或锁争用 - 行号（
LINE#）映射依赖存储过程编译时带DEBUG信息：ALTER PROCEDURE your_proc COMPILE DEBUG，否则行号错位，定位失效
DBMS_PROFILER 只告诉你“哪行 PL/SQL 慢”，不解释“为什么慢”。拿到高耗时行号后，必须提取出它触发的真实 SQL，再用 EXPLAIN PLAN FOR 或查 v$sql 看执行计划、逻辑读、等待事件——这才是根因所在。
