2. Oracle Cloud基础设施与数据库服务选型
在Oracle Cloud（OCI）上建设高可用数据库系统，第一步不是打开控制台创建实例，而是把“区域—可用域—故障域”这层物理与逻辑拓扑想清楚，再决定用哪种数据库服务承载业务。选型错了，后面再多的Data Guard、RAC或备份策略都只是补救。
区域、可用域与故障域：高可用的地基
OCI的层级结构是：区域（Region）→ 可用域（Availability Domain, AD）→ 故障域（Fault Domain, FD）。区域是地理上独立的数据中心群，例如“日本东部（东京）”和“日本西部（大阪）”；可用域是区域内相互隔离的物理数据中心，拥有独立的电力、冷却和网络；故障域则是可用域内部的硬件分组，同一AD内不同FD的实例不会共享同一机架电源。
关键约束在于：一个区域通常有1～3个AD，具体数量由区域决定。东京、大阪、首尔等区域为3个AD，部分区域只有1个AD。这直接决定了高可用架构的上限——如果区域只有1个AD，跨AD部署RAC或Data Guard就无从谈起，只能退而求其次使用跨FD或跨区域方案。
因此，选型的第一条判断是：业务RTO/RPO要求是否允许跨区域。若要求RPO=0且RTO分钟级，优先选择3个AD的区域，把主备库放在不同AD；若只能接受跨区域，则需评估跨区域网络延迟（通常东京—大阪约10～15ms，东京—首尔约30ms）对Data Guard同步模式的影响。
计算与存储资源规划
确定区域和AD后，进入资源规划。OCI数据库服务的计算资源以OCPU为单位（1 OCPU ≈ 2 vCPU），存储以GB为单位，但不同服务的规划逻辑差异很大。
DB Systems采用“Shape + 存储”模式。以VM shape为例，可选VM.Standard.E4.Flex，按OCPU和内存弹性配置。存储方面，DB Systems使用块存储（Block Volume），需分别规划数据盘、恢复区（RECO）和重做日志盘。一个典型的中等规模示例：4 OCPU、64GB内存、数据盘500GB、RECO 1TB、重做日志盘200GB。重做日志盘建议单独放置以获得稳定IOPS，这是很多初学者容易忽略的点。
Exadata Cloud Service（含ExaCC和ExaDB-D）以“数据库节点 + 存储单元”为单位。ExaCC最小配置为2个数据库节点（每节点约126 OCPU）加3个存储单元，存储裸容量约84TB。规划时关注的是数据库节点数量、存储单元数量、Exadata版本，而不是单个OCPU。Exadata的智能扫描（Smart Scan）和存储索引（Storage Index）能把过滤下推到存储层，因此同样的业务负载，Exadata所需计算资源通常低于普通DB Systems。
Autonomous Database最简化：只需选择OCPU数量和存储容量（或使用自动扩缩容），底层由Oracle管理。ADW/ATP的存储从1TB起步，OCPU从1起步，支持自动扩展至3倍。规划重点从“配多少资源”转向“设什么自动扩缩容策略”。
三种数据库服务的适用场景对比
选型的核心不是“哪个最好”，而是“哪个匹配当前团队能力和业务约束”。
| 维度 | DB Systems | Exadata Cloud Service | Autonomous Database |
|---|---|---|---|
| 管理粒度 | OS、数据库、补丁均需自行管理 | 数据库由客户管理，基础设施由Oracle管理 | 全托管，客户只管理数据和SQL |
| 高可用能力 | 支持RAC、Data Guard、跨AD部署 | 内置RAC，支持Data Guard、跨AD/跨区域 | 内置ADG，自动故障切换，无需手动配置 |
| 性能特征 | 依赖块存储IOPS，适合通用负载 | 智能扫描、存储索引、RDMA，适合高并发分析 | 自动索引、自动分区，适合混合负载 |
| 典型场景 | 需要OS级控制、自定义参数、第三方工具集成 | 核心ERP、大型OLTP+OLAP混合、极致性能要求 | 快速交付、开发测试、SaaS、无DBA团队 |
| 运维投入 | 高 | 中 | 低 |
一个实用的判断路径是：如果团队有专职DBA且业务需要OS级控制，选DB Systems；如果业务对性能和可用性要求极高且预算充足，选Exadata；如果希望快速上线、减少运维、接受一定程度的自动化约束，选Autonomous Database。
选型检查清单
在最终决策前，建议逐项确认以下问题：
- 目标区域是否有至少2个可用域？若只有1个，高可用方案是否降级为跨区域？
- 业务RTO/RPO要求是否明确？RPO=0是否必须？
- 团队是否具备OS和数据库补丁管理能力？
- 是否存在必须使用OS级工具或自定义参数的场景？
- 存储IOPS需求是否超过块存储上限？是否需要Exadata的智能扫描？
- 预算模型是CAPEX倾向还是OPEX倾向？
把这些问题的答案写下来，再对照三种服务的特性，选型就不再是拍脑袋的决定，而是有据可依的工程判断。