db time长期显著高于elapsed×cpu数表明资源排队，是扩容强信号；但需先排除sql或配置问题，再结合load profile中logical/physical reads、redo size/s的持续稳定增长趋势判断真实负载，方可进入容量建模。
看 db time 和 load profile 判断是否真需要扩容
db time 长期显著高于 elapsed time × cpu count，说明数据库在排队等待资源（比如 cpu、i/o、锁），这是扩容的强信号；但别急着加机器——先确认是不是 sql 或配置问题导致的虚假高负载。load profile 里的 logical reads per second、physical reads per second、redo size per second 这三项最能反映真实工作负载强度。如果它们在业务峰值时段持续上扬且斜率稳定，才值得进入容量建模阶段。
用 DBA_HIST_TBSPC_SPACE_USAGE 算表空间日均增长量
AWR 本身不预测增长，但 DBA_HIST_TBSPC_SPACE_USAGE 每小时记录一次已用块数，是唯一可信赖的趋势源。容易踩的坑包括：
- 直接用
TABLESPACE_USEDSIZE当字节数——它单位是数据库块，必须关联DBA_TABLESPACES查出BLOCK_SIZE才能换算：ROUND(tablespace_usedsize * block_size / 1024/1024/1024, 3) - 同一天多个快照取平均值——应取
MAX(USED_SIZE_GB)，防低估峰值占用 - 用
TO_DATE或EXTRACT算天数差——推荐TRUNC(rtime) - DATE '2026-01-01'构造线性回归 X 轴 - 只跑
REGR_SLOPE就交报告——必须搭配REGR_INTERCEPT反推起始用量，验证模型是否贴合实际（比如某次大导入后斜率突变，就得拆段拟合）
从 Redo size 推算 RDS/EC2 实例规格
迁移上云或扩容时，Redo size per second 是估算 I/O 和网络带宽的关键输入。例如 AWR 显示该值为 1.09 MB/s，则：
- 20 分钟写入量 ≈ 1.09 × 60 × 20 ÷ 1024 ≈ 1.3 GB
- 30 分钟写入量 ≈ 2.0 GB
- 若目标平台是 Amazon RDS for Oracle，建议选择支持至少 250 MiB/s 吞吐的实例类型（如
db.r6g.4xlarge），并确保存储类型（gp3 vs io2）满足持续写入压力 - 注意：该估算仅对 Oracle 引擎准确；迁到 Aurora 或 PostgreSQL 时，redo 模式完全不同，不能直接套用
别漏掉 baseline 和快照保留策略的影响
AWR 数据质量直接受 DBA_HIST_SNAPSHOT 保留天数和 baseline 设置影响。常见陷阱：
- 默认快照保留 8 天，但业务系统可能需要 90 天趋势——需提前调大
retention参数，否则历史拐点数据丢失 -
SYSAUX表空间暴涨常因 baseline 积压，删快照前务必检查DBA_HIST_BASELINE，调小 baseline 窗口或删除无用 baseline - 扩容决策若依赖近 7 天数据，而系统刚经历大促（流量非典型），结论会严重失真——应拉长观察窗口，并交叉验证
DBA_HIST_SEG_STAT中段级增长（比如某张日志表单日涨 50GB）
