📚 课程目录第3章容量数据采集与基线建立

3. 容量数据采集与基线建立

容量规划的第一步不是“算容量”，而是“拿到可信的数据”。如果连数据库过去半年增长了多少、表空间什么时候会满、I/O 峰值出现在哪个时段都说不清楚，后续的任何扩容建议都只是猜测。本节要解决的核心问题是：用哪些工具、采集哪些指标、以什么粒度、如何形成可对比的容量基线。

一、采集什么：三类核心容量数据

容量数据可以归纳为三条主线，它们分别回答不同的问题：

空间增长数据：表空间/数据文件使用量、段（segment）增长、归档日志与闪回区占用。回答“什么时候会满”。
负载与 I/O 数据：DB Time、每秒逻辑读/物理读、每秒事务数、Top 等待事件、I/O 响应时间。回答“系统有多忙、瓶颈在哪”。
资源消耗数据：CPU 使用率、内存（SGA/PGA）使用、会话数、进程数、连接数峰值。回答“主机和实例还能撑多久”。

这三类数据必须带时间戳、按固定周期采集，否则无法形成趋势。单点快照只能说明“此刻”，基线需要的是“随时间变化的曲线”。

二、用什么工具采集

Oracle 提供了从实例内部到操作系统层面的多层采集手段，实际工作中通常组合使用：

工具/视图	采集内容	典型用途
AWR（DBA_HIST_*）	快照级负载、等待、SQL、I/O 统计	历史趋势分析，默认保留 8 天，可调
Statspack	类似 AWR 的统计快照	无 Diagnostics Pack 许可时的替代方案
DBA_FEATURE_USAGE_STATISTICS	特性使用情况与首次/最近使用时间	判断分区、压缩、并行等特性是否在用
V$ 动态视图	实时空间、会话、I/O、等待	即时诊断与脚本化采集
OS 工具（iostat/vmstat/top）	主机 CPU、内存、磁盘吞吐与延迟	区分数据库内部瓶颈与主机瓶颈

需要特别说明：AWR 依赖 Diagnostics Pack 许可，Statspack 是免费替代。两者采集思路一致，都是“定时打快照，再对比快照区间”。

三、关键采集语句示例

下面给出几条可直接用于日常采集的语句，建议封装为脚本按小时或按天执行，输出到容量数据表。

-- 1. 表空间使用率（含自动扩展上限）
SELECT d.tablespace_name,
       ROUND(d.bytes/1024/1024,1)            AS alloc_mb,
       ROUND(NVL(f.free_bytes,0)/1024/1024,1) AS free_mb,
       ROUND((d.bytes-NVL(f.free_bytes,0))/d.bytes*100,1) AS used_pct
FROM   (SELECT tablespace_name, SUM(bytes) bytes
        FROM dba_data_files GROUP BY tablespace_name) d,
       (SELECT tablespace_name, SUM(bytes) free_bytes
        FROM dba_free_space GROUP BY tablespace_name) f
WHERE  d.tablespace_name = f.tablespace_name(+)
ORDER  BY used_pct DESC;

-- 2. 近 7 天每日归档日志生成量（判断日志增长）
SELECT TRUNC(completion_time) day,
       ROUND(SUM(blocks*block_size)/1024/1024/1024,2) arch_gb
FROM   v$archived_log
WHERE  completion_time > SYSDATE-7
GROUP  BY TRUNC(completion_time) ORDER BY 1;

-- 3. 从 AWR 取快照区间负载趋势
SELECT snap_id, begin_interval_time,
       ROUND(db_time/1000000,1) db_time_sec
FROM   dba_hist_snapshot s
JOIN   dba_hist_sys_time_model m
       ON s.snap_id = m.snap_id
WHERE  stat_name = 'DB time'
  AND  begin_interval_time > SYSDATE-30
ORDER  BY snap_id;

第一条语句给出当前使用率，第二条给出归档增长速度，第三条给出负载趋势。三者结合，才能判断“空间在涨、负载在涨、还是两者都在涨”。

四、建立容量基线

基线不是某一天的数值，而是一段稳定运行期内指标的统计特征。建议按以下方式建立：

选择基线窗口：取业务稳定、无重大变更的连续 4～8 周数据，避开大促、上线、迁移等异常期。
按周期聚合：空间类按天，负载类按小时或按业务高峰时段，形成“日均值 + 峰值”。
记录分位数：不要只记平均值。CPU、I/O 延迟、会话数应记录 P50、P95、P99，因为容量风险往往出现在尾部。
标注变更点：任何 DDL、参数调整、版本升级都要在基线上打标记，否则趋势会被误读。

一个可用的基线记录应至少包含：指标名、采集时间、粒度、均值、P95、峰值、对应业务时段、备注变更。这样当某天使用率突然跳升时，可以快速判断是自然增长还是异常。

基线建立后并非一劳永逸。建议每季度复核一次，或在发生重大业务/架构变更后立即重建，否则基线会逐渐失去参考价值。

五、采集与基线的关系

采集是“取数”，基线是“定标”。采集频率过低会漏掉峰值，过高则产生大量噪声和存储开销。实践中常用“小时级采集 + 日级聚合 + 周级基线”的三层节奏。下图展示了从多源采集到基线形成的完整数据流，以及各环节的关键判断点。

图中左侧是采集源，中间是采集与聚合层，右侧是基线，最右是趋势判断。可以看到，基线不是采集的终点，而是判断的起点。只有把采集数据按固定节奏聚合成带分位数的基线，才能在趋势判断中区分“正常增长”和“异常突增”。

六、常见误区与注意事项

只看平均值：平均 CPU 40% 不代表安全，P95 可能已经 90%。容量规划必须看尾部。
忽略业务周期：月末、季末、日终批处理的峰值与日常完全不同，基线要分时段建立。
采集频率与保留期不匹配：AWR 默认保留 8 天，若要做季度趋势，必须调整 retention 或自行落库。
不记录变更：一次索引重建或参数调整就可能让趋势断裂，没有变更标注就无法解释。
把 OS 与数据库数据割裂：数据库 I/O 延迟高，可能是存储层问题，必须结合 iostat 一起看。

采集脚本本身也会消耗资源。避免在业务高峰执行全表扫描式的统计查询，建议将采集任务安排在低峰期，或使用 AWR 快照等轻量机制。

总结来说，容量数据采集与基线建立的关键在于：选对工具、定好粒度、算准分位数、标清变更点。当这套机制运转起来后，后续的容量预测、扩容阈值设定和存储治理才有可靠的数据基础。