📚 课程目录第2章 Oracle数据库架构回顾与云化适配

2. Oracle数据库架构回顾与云化适配

把Oracle数据库迁移到云上，并不是简单地把服务器换成云主机。Oracle在本地数据中心形成的几套经典架构——单实例、RAC、Data Guard、多租户——在云环境中会遇到网络、存储、授权和运维模式的多重变化。理解这些变化，才能判断哪些架构可以原样平移，哪些必须改造，哪些在云上反而更简单。

单实例：云上最直接的落地形态

单实例是Oracle最基础的部署形态：一个实例对应一套数据库文件，通过SGA和后台进程访问存储。在云上，单实例通常落在计算实例加块存储的组合上。变化最大的地方是存储：本地部署常用ASM管理裸设备，云上则更多使用云盘（如块存储卷）或云文件存储。云盘本身已经具备多副本能力，因此是否继续使用ASM、是否启用ASM冗余，需要重新权衡。

适配要点集中在三处。第一，I/O特性不同：云盘的高性能型号（如SSD类）延迟和吞吐与本地SAN接近，但普通型号在随机写密集场景下可能成为瓶颈，因此db_block_size、redo日志大小、filesystemio_options等参数要结合云盘实测调整。第二，网络存储的挂载方式影响可用性，建议把数据文件、redo、归档分别放在不同卷上，避免单卷故障同时影响多类文件。第三，备份策略要改为云原生方式，例如使用对象存储做归档和备份落地，而不是继续依赖本地磁带库。

一个常见的教学示例是：在云主机上创建单实例，数据文件放在高性能云盘，redo放在独立的高IOPS卷，归档通过RMAN直接写入对象存储。判断是否达标，可以观察V$SYSTEM_EVENT中db file sequential read的平均等待时间，若长期高于5毫秒，说明存储层需要升级或调整。

RAC：云上可用但约束更多

RAC通过共享存储和集群件让多个实例同时访问同一套数据库，提供高可用和横向扩展。云化后，RAC仍然可以部署，但前提是云平台支持共享块存储和组播/单播心跳网络。很多公有云的块存储默认不支持多挂载，或者需要专门的高性能共享存储产品，这是RAC上云的第一道门槛。

第二道门槛是网络。RAC的Cache Fusion依赖节点间低延迟互联，云上跨可用区延迟通常在1～2毫秒，跨地域则高得多。因此RAC节点应尽量放在同一可用区或同一低延迟区域，私有网络要保证心跳网卡独立、带宽充足。第三是授权：Oracle对云上RAC的授权有专门规定，部分云厂商的托管服务已经包含授权，自建RAC则需要单独核算。

适配时，建议把RAC定位为“高可用优先”而非“无限扩展”。云上更常见的做法是：核心库用两节点RAC保证故障切换，读扩展交给Active Data Guard或只读副本，而不是盲目增加RAC节点。判断RAC是否健康，重点看GV$GES_STATISTICS的全局等待和GV$INSTANCE的互联状态。

Data Guard：云上容灾的主力

Data Guard通过redo传输把主库变更同步到备库，是Oracle最成熟的容灾方案。云化后，Data Guard的形态基本不变，但网络路径和存储位置变了。主备库可以跨可用区、跨地域部署，也可以主库在本地、备库在云上，形成混合容灾。

适配要点有三。第一，传输模式要结合云网络延迟选择：同地域低延迟可用最大保护或最高可用，跨地域通常用最高性能加异步传输，避免主库被网络抖动拖慢。第二，归档和redo的落地位置要重新规划，备库的LOG_ARCHIVE_DEST应指向云存储，并配合FAL_SERVER、FAL_CLIENT保证日志缺口能自动补齐。第三，切换演练要纳入云环境，验证DNS、连接串、应用重连是否同步切换。

一个可参考的配置片段如下：

-- 主库
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
 'SERVICE=standby_svc ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
  DB_UNIQUE_NAME=stdby' SCOPE=BOTH;
-- 备库
ALTER SYSTEM SET FAL_SERVER='primary_svc' SCOPE=BOTH;
ALTER SYSTEM SET FAL_CLIENT='standby_svc' SCOPE=BOTH;

判断同步是否正常，可在主库查询V$ARCHIVE_DEST_STATUS的STATUS和GAP_STATUS，备库查询V$DATAGUARD_STATS的apply lag。若apply lag持续增长，说明备库应用能力不足或网络带宽不够。

多租户：云上整合的关键抓手

多租户架构用一个CDB承载多个PDB，是云上数据库整合、快速交付和资源隔离的核心手段。云化后，多租户的价值更加突出：一个CDB可以服务多个业务，PDB可以按需创建、克隆、插拔，非常适合云上“数据库即服务”的交付模式。

适配要点在于资源管理和生命周期。云上多个PDB共享CDB的SGA和后台进程，必须用Resource Manager限制每个PDB的CPU和并行度，避免互相争抢。PDB的创建、克隆、迁移要纳入自动化流程，例如用CREATE PLUGGABLE DATABASE配合云平台API完成。备份也要从CDB和PDB两个粒度分别考虑，PDB级恢复能显著缩短单业务故障的恢复时间。

下面这张图把四种架构在云环境中的关键变化、主要限制和适配方向放在一起对照，便于快速定位每种架构的改造重点。

四种架构的协同与取舍

实际云上很少只用一种架构。常见组合是：核心交易库用两节点RAC保证高可用，通过Data Guard把redo同步到同城或异地备库，备库以多租户形式承载多个PDB，既做容灾又做读扩展。这种组合把RAC的故障切换、Data Guard的容灾、多租户的整合能力叠加在一起，但也带来复杂度：RAC与Data Guard的角色切换、PDB在备库上的同步、资源管理策略在主备之间的一致性，都需要提前设计。

取舍的核心判断标准是恢复目标。如果业务能接受分钟级中断，单实例加Data Guard就足够；如果要求秒级切换且读负载高，RAC加Active Data Guard更合适；如果云上要快速交付多个小库，多租户是首选。不要为了“架构完整”而堆叠组件，每增加一层都会增加云网络、授权和运维成本。

云化适配的通用原则：先确认云平台对共享存储、组播网络、授权模式的支持边界，再决定架构形态；存储和网络参数必须基于云盘实测调整，不能照搬本地经验值。

RAC和Data Guard在云上跨可用区部署时，务必先测量节点间和主备间的实际网络延迟。延迟超过预期会直接导致Cache Fusion等待升高或redo传输积压，表现为业务响应变慢，而这类问题在本地环境中往往不会出现。

把四种架构放在一起看，云化适配的本质是：计算和存储解耦后，I/O路径和网络路径成为新的关键变量；授权和托管模式决定了哪些架构可以自建、哪些应交给云服务；而多租户则把“一个数据库服务一个业务”的传统模式，改造成“一个CDB服务多个PDB”的整合模式。理解这些变化，后续的迁移方案、参数调优和容灾设计才有正确的出发点。