用V$SQL+手动打点表组合比DBMS_PROFILER更准、更轻、更可控；后者仅适合开发阶段单次深度分析，生产环境慎用，因其不记录wall-clock时间、会话隔离、RAC下停采样不彻底、NATIVE模式失效且Oracle 12.1+已标记为legacy。
直接结论：用 v$sql + 手动打点表组合，比 dbms_profiler 更准、更轻、更可控；dbms_profiler 仅适合开发阶段单次深度分析，生产环境慎用。
为什么不用 DBMS_PROFILER 做生产埋点
它不记录 wall-clock 时间，只统计采样时间片，单次执行耗时无法还原；DBMS_PROFILER.START_PROFILER 和 STOP_PROFILER 必须显式调用，且只对当前会话生效——调度任务（如 DBMS_SCHEDULER）跑的存储过程默认不在你的会话里，根本捕不到。
常见错误现象：PLSQL_PROFILER_DATA 查不到数据，但 PLSQL_PROFILER_RUNS 显示状态为 RUNNING；本质是 profiler 没在目标会话中启动，或目标存储过程没用 COMPILE DEBUG 重编译。
另外几个硬限制：
-
DBMS_PROFILER在 Oracle 12.1+ 默认禁用，且官方已标记为 legacy - RAC 环境下
STOP_PROFILER只停本节点，其他实例仍在采样 -
PLSQL_CODE_TYPE = NATIVE时完全失效，必须设为INTERPRETED并重编译
推荐方案：轻量级打点表 + SQL_ID 关联
核心思路：在存储过程开头/关键步骤插入时间戳到自定义日志表，同时用 sys_context('userenv', 'sid') 或 dbms_utility.format_call_stack 记录上下文，并关联 V$SQL 中的 sql_id 和 elapsed_time。
建表示例（含关键字段）：
CREATE TABLE t_proc_monitor ( id NUMBER GENERATED BY DEFAULT AS IDENTITY, proc_name VARCHAR2(128), step_name VARCHAR2(128), -- 如 'start', 'after_merge', 'end' sid NUMBER, sql_id VARCHAR2(13), begin_time DATE, end_time DATE, elapsed_sec NUMBER(10,3), detail VARCHAR2(500) );
关键操作建议：
- 在存储过程入口处立即插入
step_name = 'start'行，用SYSDATE记begin_time - 每个关键 DML（如
INSERT ... SELECT、大表UPDATE）后，查v$sql获取刚执行语句的sql_id和elapsed_time，再插入对应step_name - 结尾统一插入
step_name = 'end'，并用(SYSDATE - begin_time) * 24 * 3600算出总耗时 - 避免在循环体内高频插入日志，可加条件控制（如每 1000 行记一次）
如何从 V$SQL 中捞出刚执行的 SQL 耗时
V$SQL 不保证实时可见，尤其短 SQL 可能被快速老化。稳妥做法是：在关键语句后立刻查，且限定范围。
示例查询（放在 PL/SQL 块中）：
SELECT sql_id, elapsed_time/1000000 elapsed_sec, executions FROM v$sql WHERE sql_text LIKE '%your_target_table%' AND last_active_time > SYSDATE - 1/1440 -- 1分钟内 ORDER BY last_active_time DESC FETCH FIRST 1 ROW ONLY;
注意点：
-
sql_text是截断的（最多 1000 字符），匹配要用LIKE+ 关键字，别依赖全等 -
elapsed_time是累计值，如果该 SQL 多次执行，需结合executions算平均 - 若查不到，说明 SQL 已被 aged out，此时只能依赖你打点表里的
SYSDATE差值
容易被忽略的细节
真实线上环境里，最常漏掉的是事务边界和异常路径。
比如：存储过程中间报错 EXCEPTION，但没在 WHEN OTHERS 里补写 end_time 和 result 标记，导致监控表里永远卡在 step_name = 'after_update'，查不出失败原因。
另一个坑是时间精度：Oracle 的 DATE 类型只有秒级精度，若需毫秒级，必须用 SYSTIMESTAMP 并存为 TIMESTAMP 字段，否则两个紧挨着的操作可能显示“耗时 0 秒”。
最后提醒一句：所有打点 INSERT 都要加 COMMIT（或设为自治事务），否则会话一崩，日志全丢。
