DBMS_MONITOR本身不统计执行频率，仅开启跟踪；DBA_HIST_PROCEDURE_STATS并不存在，Oracle无类似SQL Server的sys.dm_exec_procedure_stats视图。
dbms_monitor 本身不统计存储过程执行频率，它只负责开启/关闭跟踪，后续必须配合 tkprof 或 ash 分析才能得到执行次数。
为什么直接查 DBA_HIST_PROCEDURE_STATS 行不通？
Oracle 没有类似 SQL Server 的 sys.dm_exec_procedure_stats 这样的内置视图来直接汇总存储过程的执行频次。DBA_HIST_PROCEDURE_STATS 并不存在——这是常见误判点。你查到的所谓“过程统计”，实际是间接推导出来的：
– 存储过程里每条 SQL 都有 DBA_HIST_SQLSTAT 记录；
– 但无法自动关联到“哪次 SQL 执行属于哪个过程调用”；
– 如果过程内含动态 SQL、多分支逻辑或异常处理路径，SQL_ID 和过程名之间更无稳定映射。
DBMS_MONITOR 能做什么、不能做什么？
DBMS_MONITOR 是开启会话级或服务级 SQL 跟踪的开关，不是计数器。它生成的是原始 .trc 文件，里面包含：
– 每条语句的解析、执行、获取阶段耗时
– 绑定变量值（level 12 时）
– 真实的调用堆栈（显示 PL/SQL 单元名，如 SP_CALCULATE_REPORT）
但它不输出“该过程被执行了 N 次”这种聚合结果。
常见错误操作：
– 只运行 DBMS_MONITOR.SESSION_TRACE_ENABLE 就以为万事大吉
– 忘记设置 waits => TRUE, binds => TRUE 导致关键上下文丢失
– 跟踪时间过长导致 .trc 文件超百 MB，tkprof 处理失败
真正可落地的执行频率统计流程
必须分三步走，缺一不可：
– 第一步：定向跟踪
用 DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE 锁定业务服务名 + 模块名（比如 service_name = 'ERP_APP', module_name = 'REPORT_PKG'），避免全库噪音
– 第二步：提取调用痕迹
用 tkprof 解析后，在输出中搜索 PL/SQL procedure 或 EXEC # 行，再人工匹配过程名（注意大小写和 owner 前缀）
– 第三步：补足时间维度
若需按小时/天统计，必须结合 DBA_HIST_SNAPSHOT.BEGIN_INTERVAL_TIME 对齐快照时间，并用 DBA_HIST_SQLSTAT.EXECUTIONS_DELTA 反向估算——但这仅适用于过程体中 SQL_ID 固定、且未被硬解析覆盖的场景
容易被忽略的关键细节
– DBMS_MONITOR 开启后，跟踪文件默认写入 user_dump_dest，但 Oracle 12c+ 默认启用 ADRCI，实际路径可能在 diag/rdbms/<db>/<inst>/trace/ 下，不是老式 udump
– 同一个存储过程被不同会话并发调用时，tkprof 输出里会出现多个 EXEC 记录，但它们共享同一个 SQL_ID —— 不能直接等同于“执行次数”，要数 EXEC # 行而非 SQL_ID 出现频次
– 如果过程用了 PRAGMA AUTONOMOUS_TRANSACTION，其内部 SQL 会出现在独立事务上下文中，常规跟踪可能漏掉这部分调用
