传统的 Oracle 数据库升级往往意味着数小时的业务停机、复杂的回退计划和忐忑的运维团队。 Oracle 12.2 引入的可刷新 PDB 特性，通过 PDB 刷新（ Refreshable PDB ）技术，企业可以在几乎零停机的情况下完成数据库升级，实现“飞行中换引擎”般的平滑过渡。
这种基于 “源 - 目标”架构的升级方式，不仅大幅缩短业务影响时间，还提供了完整的回退机制和预升级测试能力。
什么是 PDB 刷新升级
PDB 刷新升级的核心思想是分离与同步。它在目标 CDB 中创建一个源 PDB 的“镜像”，通过持续同步机制保持两者数据一致，最终通过简单切换完成升级。
整个过程分为三个阶段：初始创建、增量同步和最终切换。初始创建阶段，源 PDB 被以只读方式克隆到目标 CDB ；增量同步阶段，源 PDB 的更改通过重做日志持续同步到目标；最终切换阶段，业务连接从源 PDB 转向已升级的目标 PDB 。
与传统升级方式相比， PDB 刷新提供了多重优势。几乎零停机时间是最大亮点，业务仅在最终切换的几分钟内受影响。完整的回退保障让升级更安心，如遇到问题可立即切回源 PDB 。预升级验证成为可能，可在目标环境充分测试后再决定切换。
环境准备：升级前的必要检查
以下是必须满足的先决条件和检查要点：
版本兼容性是首要考虑。源 CDB 可以是 12.2 或更高版本，目标 CDB 必须是 19c 或更高版本。两个 CDB 必须运行在相同字节序的平台上。例如，从 19c 升级到 23c 是典型场景。
网络与存储配置需要精心规划。源和目标 CDB 之间必须建立数据库链接，确保网络延迟稳定在合理范围。共享存储或相应配置必须到位，以支持克隆操作。
参数与设置检查不可忽视。源 PDB 必须 undo 本地启用，归档模式必须启用并确保归档日志可访问。
以下是关键的环境检查脚本：
-- 数据库版本： select * from v$version; -- 检查源PDB状态 SELECT name, open_mode, undo_option FROM v$pdbs WHERE name = 'SOURCE_PDB'; -- 验证归档模式 archive log list; -- 字节序平台兼容 select db.name,db.platform_id,db.platform_name,os.endian_format from v$database db,v$transportable_platform os where db.platform_id=os.platform_id; -- 评估升级准备状态 EXECUTE dbms_preup.run_preup_checks;
存储空间评估同样重要。需要确保目标 CDB 有足够空间容纳源 PDB 的完整克隆，并预留额外的空间用于升级过程中的临时需求。一般建议预留源 PDB 大小 150% 的空间。
PDB 刷新升级具体步骤
以下是基于真实案例的 PDB 刷新升级完整流程，从 19c 升级到 23c 版本：
第一步：目标 CDB 环境搭建
在目标服务器上安装 Oracle 23c 软件，创建新的 CDB 容器数据库：
CREATE DATABASE TARGET_CDB
...
ENABLE PLUGGABLE DATABASE
FILE_NAME_CONVERT = ('/u01/app/oracle/oradata/SOURCE_CDB/',
'/u01/app/oracle/oradata/TARGET_CDB/');
第二步：创建数据库链接
在目标 CDB 中创建指向源 PDB 的数据库链接：
-- 在目标CDB中执行 CREATE DATABASE LINK source_link CONNECT TO system IDENTIFIED BY password USING '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP) (HOST=source_host)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=SOURCE_PDB)))';
第三步：创建可刷新 PDB
在目标 CDB 中创建源 PDB 的可刷新克隆：
CREATE PLUGGABLE DATABASE target_pdb FROM source_pdb@source_link REFRESH MODE EVERY 60 MINUTES;
初始创建完成后，目标 PDB 处于同步就绪状态，开始接收源 PDB 的变更。
第四步：启动定期刷新
根据业务容忍度设置刷新频率，通常为 15-60 分钟：
ALTER PLUGGABLE DATABASE target_pdb REFRESH MODE EVERY 30 MINUTES;
刷新过程中，源 PDB 保持完全可读写，业务不受任何影响。
第五步：预升级测试与验证
在最终切换前，可在目标 PDB 上进行全面测试：
-- 打开目标PDB进行测试 ALTER PLUGGABLE DATABASE target_pdb OPEN READ ONLY; -- 运行应用测试套件 -- 检查性能与兼容性 -- 验证数据完整性 -- 测试完成后关闭 ALTER PLUGGABLE DATABASE target_pdb CLOSE;
第六步：最终刷新与切换
安排维护窗口，执行最终手动刷新并切换业务：
-- 执行最终手动刷新，确保数据完全同步 ALTER PLUGGABLE DATABASE target_pdb REFRESH; -- 关闭源PDB，停止业务写入 ALTER PLUGGABLE DATABASE source_pdb CLOSE IMMEDIATE; -- 执行最后一次刷新 ALTER PLUGGABLE DATABASE target_pdb REFRESH; -- 打开目标PDB，指向业务连接 ALTER PLUGGABLE DATABASE target_pdb OPEN UPGRADE; -- 运行升级脚本 @?/rdbms/admin/utlu23i.sql @?/rdbms/admin/catctl.pl -n 8 -l /tmp catupgrd.sql -- 完成升级后正常打开 ALTER PLUGGABLE DATABASE target_pdb OPEN;
第七步：回退准备与清理
为确保安全，保留源 PDB 一段时间作为回退保障：
-- 保持源PDB一周，确保升级稳定 -- 一周后确认升级成功，清理源PDB DROP PLUGGABLE DATABASE source_pdb INCLUDING DATAFILES;
避坑指南：常见问题与解决方案
在实际操作中，以下几个问题需要特别注意：
刷新延迟问题是最常见的挑战。如果网络不稳定或源系统负载过高，可能导致刷新延迟。解决方案是监控刷新间隔，调整刷新频率以适应网络条件。可使用以下查询监控刷新状态：
SELECT pdb_name, refresh_mode, refresh_interval, last_refresh_scn, last_refresh_date FROM dba_pdbs WHERE refresh_mode IS NOT NULL;
存储空间不足是另一个常见问题。克隆操作需要额外空间，特别是在初始创建阶段。建议提前规划存储，监控表空间使用情况：
SELECT tablespace_name, round(SUM(bytes)/1024/1024/1024, 2) size_gb, round(SUM(maxbytes)/1024/1024/1024, 2) max_size_gb FROM dba_data_files GROUP BY tablespace_name;
性能影响管理至关重要。刷新操作会消耗源系统和网络资源。建议在业务低峰期执行初始克隆，并监控系统性能指标。如果发现性能影响过大，可以调整刷新间隔或优化网络配置。
兼容性问题预防不容忽视。某些特性或对象可能无法通过刷新同步。建议使用预升级检查工具提前识别问题：
-- 运行预升级检查 @?/rdbms/admin/preupgrd.sql -- 查看检查结果 SELECT * FROM preupg_results;
随着 Oracle 多租户架构的普及， PDB 刷新升级正成为企业数据库升级的首选方案。它代表了数据库运维的新范式——从“计划性中断”转向“持续可用”，从“高风险操作”转向“可控可回退的流程”。
