V$视图是实时内存快照，应直接查询而非封装进存储过程；存储过程仅适合封装诊断逻辑（如check_blocking函数），不可用于持续监测或定时轮询，因其无后台线程、增加开销且权限受限。
直接用 v$ 视图查，别写存储过程去“监测”——它本身不是监控工具，而是数据源。 存储过程适合封装重复逻辑（比如批量收集统计信息），但实时性能指标必须靠查询动态视图即时获取。硬套存储过程包装一层 select，反而增加解析开销、掩盖真实延迟、还容易被误认为“有后台守护进程在跑”。
为什么不能把 V$SESSION 或 V$SYSSTAT 查询塞进存储过程里定时执行
Oracle 的 V$ 视图是内存快照，每次查询都实时拼装，毫秒级新鲜。一旦封装进存储过程中，你面临三个实际问题：
- 调用时才执行，无法“持续监测”；想轮询就得靠外部脚本（如 shell + sqlplus）驱动，存储过程自身不支持 sleep 或后台线程
- 若在存储过程中用
DBMS_OUTPUT.PUT_LINE输出，大量数据会卡住客户端缓冲区，甚至触发 ORA-20000 类错误 - 权限和上下文受限：存储过程默认以 definer’s rights 运行，
V$视图需显式授权（SELECT_CATALOG_ROLE或直接GRANT SELECT ON v_$session TO ...），且不能跨实例访问
V$SYSMETRIC 是最接近“实时指标”的视图，但依然要手动查
它每 15 秒聚合一次系统级度量（如 Database CPU Time Ratio、SQL Service Response Time），单位统一为百分比或毫秒，比轮询 V$SYSSTAT 更轻量。但它仍是只读视图，没有触发器、不支持物化，也不能自动告警。
典型用法就是一条 SQL：
SELECT metric_name, value, metric_unit
FROM v$sysmetric
WHERE metric_name IN ('Database CPU Time Ratio', 'SQL Service Response Time')
AND intsize_csec > 0;
注意：intsize_csec 表示该指标采集窗口长度（厘秒），值为 0 说明尚未完成本轮采集，跳过即可。
真要封装，只封装“诊断逻辑”，别碰“采集动作”
比如你想快速判断当前是否存在严重锁等待，可以写一个函数返回字符串结果，而不是试图让存储过程“每 5 秒检查一次”：
CREATE OR REPLACE FUNCTION check_blocking RETURN VARCHAR2 IS
v_count NUMBER;
BEGIN
SELECT COUNT(*) INTO v_count
FROM v$lock l1, v$lock l2, v$session s1, v$session s2
WHERE l1.block = 1 AND l2.request > 0
AND l1.id1 = l2.id1 AND l2.sid = s2.sid AND l1.sid = s1.sid;
RETURN CASE WHEN v_count > 0 THEN 'BLOCKING_DETECTED' ELSE 'OK' END;
END;
这样调用 SELECT check_blocking FROM dual; 才有意义。但请记住：
- 这函数每次执行都重新查
V$，不是“常驻监控” - 别在函数里做
COMMIT或 DML，V$视图只读，且函数内不允许事务控制 - 高并发下频繁调用可能加重 shared pool latch 争用，不如用外部脚本限频调用
真正需要“监测”的地方，应该交给 AWR 快照周期性捕获，或用外部工具（如 Prometheus + oracledb_exporter）拉取 V$ 数据并打点。存储过程在这里的角色，只是帮你把一堆条件判断、字段映射、阈值比较的 SQL 逻辑收拢成可复用单元——它不运行，也不守夜。
