1. 课程导入与容量治理全景
Oracle 数据库容量规划与存储治理，解决的不是“磁盘还剩多少 GB”这样一个单点问题，而是回答一个持续性问题：在业务负载不断变化的前提下，数据库的容量、性能、成本与可用性如何长期保持在可控区间内。容量规划偏“向前看”，通过历史增长趋势与业务预期，预测未来一段时间所需的存储、内存、I/O 与连接资源；存储治理偏“向内看”，通过清理、归档、压缩、分层、回收等手段，让已占用的空间产生应有的价值。两者合在一起，才构成完整的容量治理闭环。
很多团队的真实困境并不是“没有监控”，而是“监控数据很多，却无法支撑决策”。表空间使用率 85% 时，究竟该扩容还是该清理？归档日志每天增长 40 GB，是调大 FRA 还是缩短保留期？某张表占了 1.2 TB，其中 70% 是三年未访问的历史数据，是分区归档还是直接压缩？这些问题的答案，取决于是否建立了统一的指标体系与判断依据。
四个核心指标：容量、性能、成本、可用性
容量治理的指标体系可以归纳为四个相互制约的维度，它们共同决定了治理策略的取舍方向。
| 维度 | 典型指标 | 观察对象 | 失衡后的表现 |
|---|---|---|---|
| 容量 | 表空间使用率、段增长速率、归档日志日增量、UNDO 保留 | DBA_SEGMENTS、DBA_TABLESPACE_USAGE_METRICS、V$ARCHIVED_LOG | 空间告警、写入失败、ORA-01653/01654 |
| 性能 | 物理读、逻辑读、DB Time、TOP 等待事件、I/O 延迟 | AWR、V$SYSSTAT、V$SESSION_EVENT | 响应变慢、I/O 瓶颈、全表扫描增多 |
| 成本 | 每 TB 存储成本、备份介质占用、冷热数据比例 | 存储账单、RMAN 备份集、数据访问频度 | 高端存储被冷数据长期占用 |
| 可用性 | FRA 使用率、备份成功率、恢复窗口、RTO/RPO | V$RECOVERY_FILE_DEST、RMAN 日志 | 归档写满、备份失败、无法恢复 |
这四个维度并非彼此独立。压缩历史数据可以降低容量与成本，但可能增加 CPU 开销，影响性能；缩短归档保留期可以缓解 FRA 压力，却会压缩恢复窗口，削弱可用性。因此容量治理的本质是在约束条件下做权衡，而不是追求单一指标的最优。
容量治理的整体工作链路
从工程视角看，容量治理是一条从“采集”到“决策”再到“执行与验证”的链路。下图展示了这条链路中各个环节的输入、处理与输出关系，以及四个核心指标在其中的位置。
本课程的学习路径与实战项目
课程围绕“看得见、算得清、动得了、守得住”四条主线展开。前段建立容量与存储的基础认知，包括表空间与数据文件结构、段与区段分配、UNDO 与临时段、归档与 FRA 的容量含义；中段进入度量与预测，讲解如何从 V$ 视图与 AWR 中提取增长趋势，如何用线性回归与移动平均做容量预测，如何识别冷热数据；后段聚焦治理手段，包括分区与归档、压缩与去重、表空间重组、数据文件在线迁移、大对象与 LOB 治理、备份与归档保留策略；末段回到工程化，讨论容量基线与告警阈值设计、治理任务的变更管理与回滚方案。
实战项目以一个模拟的订单业务库为对象，初始规模约 2 TB，包含订单主表、订单明细表、日志表与历史归档表。项目要求完成一次完整的容量治理：先采集一周的段增长与归档增量数据，建立容量基线；再识别出占用最大的前 20 个段，判断其中哪些属于冷数据；随后对冷数据表实施分区归档或压缩，并验证空间回收效果；最后输出治理前后的指标对比与后续监控建议。项目中的参数、数据量与结果均为教学示例，实际执行时需结合真实环境调整。
在进入具体技术细节之前，先建立三个基本判断习惯：第一，任何容量告警都要先区分“真实增长”与“异常膨胀”，前者需要规划，后者需要排障；第二，任何治理动作都要先评估对性能与可用性的影响，再决定执行窗口与回滚方案；第三，任何优化都要有可验证的结果指标，否则无法判断治理是否真正生效。接下来的章节将围绕这些习惯，逐步展开可落地的操作方法。