不能直接用 DBA_TABLESPACE_USAGE_METRICS 查增长，因其仅返回当前单点压缩块数且无时间字段 RTIME，无法构建时间序列；而真实趋势分析必须依赖 DBA_HIST_TBSPC_SPACE_USAGE 中带 RTIME 的历史快照，结合 DBA_TABLESPACES 换算块大小后按天取峰值建模。
awr 本身不预测增长，但 dba_hist_tbspc_space_usage 里每小时一次的块级快照，是做趋势分析唯一可信的数据源；直接查 dba_tablespace_usage_metrics 或手工估算日增 mb 都会漏掉关键时间维度和块大小差异。
为什么不能直接用 DBA_TABLESPACE_USAGE_METRICS 查增长？
这个视图只返回当前时刻的压缩块数，没有 rtime 字段，没法建模时间序列。而真实增长必须看“什么时候用了多少”，不是“现在用了多少”。你看到的数字可能是刚清理完、也可能是刚导入完，单点值毫无趋势意义。
-
DBA_HIST_TBSPC_SPACE_USAGE每小时默认采样一次（可调），保留期由dba_hist_wr_control.retention控制，默认 8 天，足够覆盖短期波动 - 字段
TABLESPACE_USEDSIZE和TABLESPACE_SIZE单位是数据库块（block），不是字节——这点不注意，算出来的 GB 就会差几倍 - 不同表空间可能有不同
BLOCK_SIZE（比如 8K 的USERS和 16K 的EXAMPLE），必须关联DBA_TABLESPACES获取对应值
怎么把 AWR 块数换算成可用的 GB 趋势数据？
核心就两步：先按块大小换算，再按天聚合峰值。别用 TO_DATE(rtime, 'YYYY-MM-DD') 截日期，Oracle 12c+ 后 rtime 格式不稳定，TRUNC(rtime) 才安全。
- 换算公式：
ROUND(tablespace_usedsize * block_size / 1024/1024/1024, 3)→ 得到当日已用 GB - 同一天多个快照（如每小时一次）取
MAX(USED_SIZE_GB)，防低估峰值占用（尤其夜间批处理后） - 聚合前加过滤：
rtime >= SYSDATE - 30，太老的数据可能被扩容、归档策略变更污染
如何用 REGR_SLOPE 算日均增长量？
Oracle 自带函数足够用，不用导出 Excel 或写 Python。斜率数值本身没那么重要，关键是看它是否稳定、有没有突变点——比如某次大导入后斜率翻倍，那就要去查 DBA_HIST_SEG_STAT 看是哪张表在撑。
- X 轴必须用数字，别直接用日期：
TRUNC(rtime) - DATE '2026-01-01'→ 第 1 天是 0，第 30 天是 29，避免日期计算溢出 - 示例 SQL 中，
REGR_SLOPE(USED_SIZE_GB, DT_NUM)返回的就是 GB/天，REGR_INTERCEPT可反推起始日用量，用来交叉验证模型是否合理 - 如果结果异常（比如负增长或超大斜率），先检查
SYSAUX是否被WRH$_ACTIVE_SESSION_HISTORY或WRI$_SQLTEST_PLAN_LINES（19.7+ 新增 ASTS 组件）占满——这类暴涨通常和业务无关，是采集机制或 BUG 导致
真正难的不是跑出一个斜率数字，而是判断这个数字背后有没有业务逻辑支撑：某张日志表没分区、新模块开始批量写入、还是某个 OLAP 工作区（查 V$AW_OLAP）突然开始高频刷新。AWR 给你的是“发生了什么”，但“为什么发生”得靠段级增长 + 应用日志交叉验证。
