dba_tablespace_usage_metrics仅反映瞬时使用率，无法预警高回滚速率导致的ora-01555等风险；必须结合v$undostat计算undoblks/((end_time-begin_time)*86400)得出每秒回滚块生成速率，且峰值速率比平均速率更具诊断价值。
直接查 dba_tablespace_usage_metrics 不够用
这个视图能快速返回当前使用率，比如 select tablespace_name, used_space, total_space from dba_tablespace_usage_metrics where tablespace_name like 'undo%'，但它只反映瞬时快照。实际运维中常遇到：使用率显示才 65%，但一条长事务正以每秒 120 个 undo 块的速度写入，10 秒内就可能触发 ora-01555 或空间争用。静态值无法预警这种“速率型风险”。
必须结合 v$undostat 算回滚块生成速率
真正决定 undo 压力的是单位时间产生的 undo 数据量，核心计算逻辑是：undoblks / ((end_time - begin_time) * 86400)。注意两点：
-
end_time - begin_time必须用字段算，不能硬写 600（Oracle 默认 10 分钟采样，但统计延迟可能导致实际差值略大于 600） - 峰值速率比平均速率更有价值——
MAX(undoblks / ((end_time - begin_time) * 86400))能暴露业务高峰的真实压力 - 如果要转成字节吞吐量，需乘以
db_block_size（查v$parameter中db_block_size值）
存储过程里怎么安全聚合历史数据
在存储过程中调用 v$undostat 时，容易踩三个坑：
-
v$undostat默认保留最近 7 天数据，但某些库因参数_collect_undostats=FALSE可能为空——执行前先SELECT COUNT(*) FROM v$undostat校验 - 聚合时必须用
SUM((end_time - begin_time) * 86400)做分母，不能对时间差取平均再除，否则会放大误差 - 建议限定时间范围，比如只查最近 24 小时：
WHERE begin_time > SYSDATE - 1，避免旧数据干扰峰值判断
告警阈值不能只看百分比
一个 32GB 的 UNDOTBS1 表空间，80% 使用率是 25.6GB，看似宽松；但如果峰值回滚速率达 150 块/秒、db_block_size=8192，那每秒产生约 1.2MB undo 数据，撑满剩余空间只需不到 2 小时。所以存储过程里该同时输出：
- 当前使用率（来自
dba_data_files和dba_free_space连查，注意NVL(SUM(bytes), 0)防空） - 最近 24 小时峰值 undo 块/秒
- 按当前峰值速率估算的耗尽时间（剩余空间 ÷ 峰值字节速率）
真正难的是把“速率”和“空间余量”放在同一时间尺度下对齐——这一步漏掉，监控就只剩数字，没有判断依据。
