📚 课程目录第1章课程导入与云化混合部署全景

1. 课程导入与云化混合部署全景

Oracle 数据库的云化与混合部署，并不是简单地把数据库从机房搬到云上，而是围绕“数据放在哪里、算力如何调度、成本与合规如何平衡”重新设计数据库的运行形态。它通常包含三种基本落点：公有云（如 Oracle Cloud Infrastructure、AWS、Azure 上的 Oracle 数据库）、私有云或本地 Exadata/ODA，以及介于两者之间的混合部署——一部分核心库留在本地，一部分业务库、灾备库、分析库或开发测试库放到云端，通过数据同步与统一运维把它们连成一个整体。

理解这门课，先要抓住一个判断：云化不等于全部上云。真正的目标是让数据库在合适的位置以合适的成本提供合适的服务等级。因此本课程会反复围绕“负载画像—部署选型—迁移与同步—运维治理”这条主线展开，而不是只讲某个云厂商的产品清单。

核心驱动力：为什么企业要把 Oracle 数据库云化

推动云化的力量通常来自四个方面。第一是弹性与敏捷：传统采购一台 Exadata 或高端 x86 服务器往往需要数月，而云上可以在小时级开通一套 RAC 或 ADG 环境，开发测试库可以按需启停。第二是成本结构：把一次性资本支出转为按需付费，同时利用云上的自动伸缩、存储分层降低闲置成本。第三是高可用与灾备：云厂商提供多可用区、跨区域复制能力，配合 Oracle Data Guard、GoldenGate 可以较低成本构建异地容灾。第四是合规与数据主权：金融、政务等行业要求核心数据留在本地，但希望非核心业务享受云的红利，这正是混合部署存在的根本原因。

需要提醒的是，云化也会带来新的约束：网络延迟、跨云带宽费用、License 携带规则（BYOL）、以及云上 Oracle 版本与补丁策略的差异。这些约束会在后续章节中逐一展开。

典型业务场景

从实践看，Oracle 数据库云化混合部署常见于以下几类场景：

核心交易库本地 + 灾备/只读库上云：本地 RAC 承载 OLTP，云端通过 Data Guard 建立物理备库，用于容灾切换和报表查询分流。
开发测试与培训环境整体上云：利用云上快速克隆能力，从生产库的 RMAN 备份或快照创建多套隔离环境，按需销毁。
数据分析与历史归档上云：将冷数据或 ODS 层迁移到云上对象存储或 Autonomous Data Warehouse，降低本地存储压力。
多云容灾与避免厂商锁定：主库在本地或云 A，备库在云 B，通过 GoldenGate 做逻辑复制，兼顾容灾与迁移过渡。

这些场景的共同点是：数据不是一次性搬完就结束，而是要在本地与云之间持续流动、保持一致，并且能被统一监控和治理。

整体技术栈与学习路径

要支撑上述场景，技术栈大致分为四层。最底层是基础设施层：计算实例、块存储、对象存储、虚拟网络与专线/VPN。往上是数据库引擎层：Oracle 单实例、RAC、Data Guard、GoldenGate、Autonomous Database 等不同形态。再往上是数据流动与集成层：RMAN 备份恢复、Data Pump、ADG 实时同步、OGG 逻辑复制、以及云厂商的 DMS 类工具。最上层是运维治理层：监控告警、备份策略、权限与审计、成本管理、以及自动化编排脚本。

学习路径建议按“先看清全貌，再动手搭一条最小链路”的方式推进：先理解部署形态与选型依据，再掌握网络与安全边界，然后练习从本地到云端的迁移与同步，最后进入高可用、性能与成本治理。下面的全景图把这条路径上的关键对象和它们之间的关系集中呈现出来，便于在后续章节中随时回看定位。

从全景到动手：一条最小可行链路

为了不让全景停留在概念层面，这里给出一个可以在实验环境中复现的最小链路示例。假设本地有一套 Oracle 19c 单实例，库名 ORCL，运行在 192.168.10.20；云端有一台已安装同版本 Oracle 的云主机，IP 为 10.0.1.30，两者已通过 VPN 打通。目标是先在云端建立一份可查询的物理备库。

-- 本地主库：确认归档模式与强制日志
SQL> SELECT log_mode, force_logging FROM v$database;
LOG_MODE     FORCE_LOGGING
------------ -------------
ARCHIVELOG   YES

-- 本地主库：配置 Data Guard 参数
SQL> ALTER SYSTEM SET log_archive_dest_2=
  2> 'SERVICE=orcldg ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcldg'
  3> SCOPE=BOTH;

-- 云端备库：使用 RMAN 从主库备份恢复
RMAN> CONNECT TARGET sys/oracle@orcl
RMAN> CONNECT AUXILIARY sys/oracle@orcldg
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;

执行完成后，在备库上查询 SELECT database_role, open_mode FROM v$database;，若返回 PHYSICAL STANDBY 与 READ ONLY WITH APPLY，说明同步链路已建立。此时可以在备库上开启实时应用：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;。随后在主库插入一条测试记录，再在备库查询，若能看到该记录，说明数据流动正常。这个最小链路覆盖了“本地主库—网络—云端备库—验证”的完整闭环，后续章节会在此基础上加入 RAC、多租户、跨云复制和成本优化。

本课程中的 IP、库名、参数值均为教学示例，实际环境需根据网络规划、Oracle 版本和 License 授权情况调整。执行 DUPLICATE 前请确认备库空间、密码文件和监听配置已就绪。

学习本课程时建议保持的三个视角

第一，始终区分“数据面”和“控制面”。数据面是真实的数据文件、日志和复制流；控制面是备份策略、监控、权限和成本规则。云化混合部署的很多问题，本质是控制面没有跟上数据面的变化。第二，把网络当作数据库的一部分。跨云延迟会直接影响 Data Guard 的同步模式和 GoldenGate 的抽取延迟，选型时必须先量化带宽与 RTT。第三，用可验证的指标判断成败，例如备库应用延迟（v$dataguard_stats 中的 apply lag）、迁移后的行数与校验和、以及单位事务的云上成本，而不是只看“是否开通成功”。