oracle不记录存储过程本身到v$sql，只记录其内部执行的sql语句；统计调用次数需自主埋点，如写入自定义日志表，而非依赖awr或数据字典视图。
查 v$sql 时为什么找不到你的存储过程？
oracle 不直接在 v$sql 中记录存储过程（procedure）本身，而是记录它内部执行的 sql 语句。如果你只查 sql_text 包含 call 或 exec 的行，大概率为空——因为 pl/sql 执行体通常被编译为字节码，不以文本形式落进共享池。
真正能反映“过程被调用”的线索，藏在 V$SQLAREA 或 V$SQL 的 program_id 和 program_line# 字段里，但前提是该过程**显式调用了可识别的 SQL 语句**（比如带绑定变量的 SELECT、INSERT），且该 SQL 没被其他逻辑复用。
-
PROGRAM_ID是ALL_OBJECTS.OBJECT_ID，可用于反查过程名，但仅当该 SQL 是由该过程首次生成并缓存时才稳定关联 - 如果过程里全是
IF/LOOP、无 SQL，它根本不会出现在V$SQL里——也就无法靠此统计“执行次数” -
V$SQL默认只保留近期活跃 SQL，重启或内存压力大时会被刷出，不能代表历史累计值
用 DBA_HIST_SQLSTAT 做小时级累计统计靠谱吗？
可以，但必须配合 DBA_HIST_SQLTEXT 和 DBA_HIST_SNAPSHOT，且只适用于启用了 AWR（Automatic Workload Repository）并保留足够快照周期的环境。它的优势是能跨天聚合，劣势是粒度粗、延迟高（默认每小时采样一次），且仍受限于“过程是否生成了唯一可追踪的 SQL”。
典型查询逻辑是：先从 DBA_HIST_SQLTEXT 找出疑似属于某过程的 SQL（例如 sql_text 包含过程名字符串或固定注释），再通过 sql_id 关联 DBA_HIST_SQLSTAT 求和 executions_delta。
- 务必加条件
dbid = (SELECT dbid FROM v$database)，否则跨库快照会混入错误数据 -
executions_delta是两次快照间的增量，需用SUM()聚合，不能直接取最大值 - 若过程频繁调用同一 SQL（如循环中查表），
executions_delta会远大于过程实际调用次数——这里统计的是 SQL 执行频次，不是过程调用频次
真正想统计“过程被调用了多少次”，只能靠自主埋点
Oracle 原生不提供“过程调用计数器”，最可靠的方式是在目标过程体开头插入一行日志写入自定义表（如 proc_call_log），并配合适当的异步提交或批量写入避免性能拖累。
CREATE TABLE proc_call_log (
proc_name VARCHAR2(100),
call_time DATE DEFAULT SYSDATE,
client_info VARCHAR2(64)
);
<p>-- 在每个要监控的过程里加：
INSERT INTO proc_call_log (proc_name, client_info)
VALUES ('MY_PACKAGE.MY_PROC', SYS_CONTEXT('USERENV', 'CLIENT_INFO'));
COMMIT; -- 或用 AUTONOMOUS_TRANSACTION 封装成独立事务</p>
- 不要用
DBMS_OUTPUT.PUT_LINE——它不持久，且依赖客户端开启缓冲 - 避免在高频过程里用普通
INSERT + COMMIT，可用序列 + 批量BULK COLLECT缓冲，或改用UTL_FILE写文件（需目录权限） -
CLIENT_INFO可记录调用来源（如应用模块名），方便后续按场景归因
DBA_PROCEDURES 和 ALL_SOURCE 能帮你定位但不能统计
这两个视图只提供元数据：过程是否存在、代码在哪、是否有效。它们对“执行频次”完全无贡献，但常被误当作起点。比如有人试图用 ALL_SOURCE 扫描所有 CREATE OR REPLACE PROCEDURE 语句来生成监控脚本——这只能帮你批量加埋点，不能替代运行时采集。
-
DBA_PROCEDURES.STATUS = 'VALID'只表示编译通过，不代表最近被调用过 -
LAST_DDL_TIME是修改时间，不是执行时间 - 若过程被
GRANT EXECUTE给多个用户，而你只查ALL_*视图，会漏掉其他 Schema 下的同名过程
真要覆盖全量，得用 DBA_PROCEDURES 构建过程清单，再逐个手工或脚本注入埋点逻辑——没有银弹，只有权衡。
