dbms_profiler不能直接定位sql慢的根因，仅标识高耗时pl/sql行号；需结合v$session_wait、v$sql和explain plan分析i/o等待、锁争用、执行计划等深层原因。
dbms_profiler 不能直接定位 sql 执行慢的根因，它只告诉你“哪行 pl/sql 耗时高”，但不告诉你“为什么那条 sql 慢”——这是最常见的误用起点。
DBMS_PROFILER 输出里看到某行耗时 98%，但实际是 SQL 等待 I/O 或锁
PL/SQL 行号（如 line# 127）显示耗时异常，并不等于该行逻辑本身重。它可能只是调用了 UPDATE 或 SELECT INTO，而真正卡住的是背后那条语句的执行：磁盘读等待、行锁争用、统计信息陈旧导致优化器选错计划。DBMS_PROFILER 不采集 SQL 执行细节，只记录 PL/SQL 控制流耗时。
- 先查
v$session_wait，看会话当前在等什么：event是db file sequential read还是enq: TX - row lock contention - 再查
v$sql中对应 SQL 的elapsed_time和buffer_gets，确认是否真慢 - 最后才用
DBMS_PROFILER确认“是不是这行触发了那条慢 SQL”
启用 DBMS_PROFILER 前必须确保三件事
否则 profiler 数据为空或严重失真：
-
GRANT EXECUTE ON DBMS_PROFILER TO your_user;—— 权限缺失会导致DBMS_PROFILER.START_PROFILER静默失败 - 目标存储过程需用
DEBUG权限编译：ALTER PROCEDURE your_proc COMPILE DEBUG;，否则行号映射失效 - 必须在同一会话中完成启动 → 执行 → 停止 → 刷新：
DBMS_PROFILER.STOP_PROFILER后立即DBMS_PROFILER.FLUSH_DATA，否则数据滞留在内存未落库
看懂 profiler 报告里最关键的两列：TOTAL_OCCUR 和 TOTAL_TIME
很多人只盯着 TOTAL_TIME 排序，却忽略 TOTAL_OCCUR。例如：
LINE# | TOTAL_OCCUR | TOTAL_TIME 127 | 50000 | 12.4 189 | 1 | 8.2
第 127 行执行了 5 万次，每次平均 0.00025 秒；第 189 行只执行 1 次，但单次耗时 8.2 秒。前者是循环体内的低效赋值或函数调用，后者很可能是某条没走索引的 SELECT。优先排查 TOTAL_OCCUR > 1 且 TOTAL_TIME / TOTAL_OCCUR > 0.01 的行——这才是真瓶颈。
DBMS_PROFILER 和 EXPLAIN PLAN 必须配合使用
定位到 PL/SQL 行后，不能只看代码，要提取出它实际执行的 SQL：
- 如果是隐式游标（
SELECT ... INTO），把变量替换成字面量，粘贴到新窗口跑EXPLAIN PLAN FOR ... - 如果是显式游标，检查
CURSOR c IS SELECT ...定义，特别注意绑定变量是否被函数包裹，比如WHERE TRUNC(log_time) = TRUNC(:p_date)—— 这会让索引彻底失效 - 对比
DBMS_XPLAN.DISPLAY中的Predicate Information：出现filter(...)而非access(...)，基本可断定索引未用于定位
最常被跳过的一步：profiler 指向了某行，但开发者直接改 PL/SQL 逻辑，没碰 SQL 本身。而真实瓶颈往往藏在那条 SQL 的谓词写法、类型匹配或统计信息里。
