记录一次Oracle 19.11使用PDB Refresh方式迁移PDB

近期在某银行生产环境做的一次PDB迁移，使用的是PDB refresh方式，记录一下流程及遇到的坑。

推荐视频：经典知识库：Oracle PDB Refresh实战分享 - 李海清

上述视频详细介绍了什么是PDB Refresh、使用场景、迁移流程，本文流程也是依照该视频为主要参考，推荐学习。

一、源库及目标库情况

源库与目标库情况：

二、迁移方式选择

根据以上的情况，认为DG与PDB refresh方式是比较好的选择。

1. DG相较于PDB refresh配置更麻烦
2. PDB refresh的前置条件比DG多
3. 停机时间来看，DG略短于PDB refresh

最后还是定的使用PDB refresh，主要是因为没在生产上做过，积累下经验，另外也简单：）

三、什么是PDB Refresh

简单来说：创建目标端到源端的DBlink，目标端create pluggable database，指向源端PDB，这样就将源端PDB copy过来，copy过程源端无需停机，再设置refresh刷新，可以将源库的增量也应用到目标端。切换时源端read only，目标端read write，完事。

注意：

1. PDB Refresh支持三种类型的源端数据库，分别是 Local PDB/PDB in a remote CDB/Non-CDB
2. PDB Refresh不支持跨平台、不支持跨大版本

四、迁移流程

4.1 准备阶段

1. 数据库版本。源库的版本不能大于目标端,可以同版本迁移或从低版本迁移到高版本，不支持高版本到低版本

sqlplus -v

1. 源端和目标端数据库必须为归档模式。源端和目标端数据库必须为归档模式

archive log list

注意： 建议源库及目标库设置归档路径使用闪回区，否则刷新时可能会遇到如下BUG，这是我踩到的坑之一！

Bug 33331329 - Intermittent ORA-65345 in Clone PDB When log_archive_dest_n=‘location=use_db_recovery_file_dest’ is Not Set (Doc ID 33331329.8)

Bug 32631551 - Refresh pluggable database fails with ORA-283: recovery session canceled due to errors ORA-65345: cannot refresh pluggable database (Doc ID 32631551.8)

1. 字符集。源库pdb的字符集要和目标CDB的字符集和国家字符集兼容，例如目标库是AL32UTF8的话，源库可以是ZHS16GBK，但是反过来就不行

select userenv('language') from dual;

1. 字节序。源库目标库需要相同

set lines 120
col platform_name for a20
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;

1. PDB必须使用本地UNDO表空间

col property_name for a30
col property_value for a20
select property_name,property_value from database_properties where property_name='LOCAL_UNDO_ENABLED';

--切换到PDB下查看undo表空间是否存在
select name from v$datafile where name like '%undo%';

参考：Undo Modes in 12.2 Multitenant Databases - Local and Shared Modes (Doc ID 2169828.1)

1. 数据库组件。目标库的组件要与源库一致，或者包含源库的组件，如果源库安装的组件比目标库多，需要在源库PDB下先删掉多出的组件，删除方式参考文章开头的推荐链接查看。这也是个坑，务必提前检查

select comp_id from dba_registry where status!='REMOVED';

1. 确保目标库库CDB有足够的剩余SGA/PGA内存分配给refresh PDB；
2. 确保目标库磁盘组有足够的剩余可用空间（数据文件物理空间）存放迁移过去的PDB并有适量余量。
3. 如果目标cdb中存在users表空间，且被其他c##用户使用着，需要在源pdb预先创建users表空间。
4. 源库目标库检查OMF是否启用，没启用的话，克隆时需要指定filel_name_convert参数

show parameter db_create_file_dest

11.另外参考视频中还提到：源库pdb中可能存在目标库cdb中没有的c##用户。需要进行删除操作。 生产环境不太适合删除，我是在目标库创建相同账户处理。

4.2 同步阶段

1. 源库创建container用户

create user C##hf_refresh identified by Password123 container=all;
grant create session,sysoper,create pluggable database to c##hf_refresh container=all;

1. 目标库创建dblink连接到源库CDB

create public database link hf_refresh_dblink connect to c##hf_refresh identified by Password123 using '10.9.xxx.xx:1521/RAP010';

1. 目标端创建clone refresh pdb，创建完成为mounted状态(我实际操作7T，2小时内create完成)

--由于不确定多久能create完成，所以使用脚本后台执行，这里我们设置create完成后每10分钟自动刷新
#!/bin/bash
export ORACLE_SID=xxxx
echo $ORACLE_SID;
sqlplus -S / as sysdba<<eof
show pdbs;
create pluggable database xxx from xxx@hf_refresh_dblink refresh mode every 10 minutes;
show pdbs;
eof

关于刷新方式：

--设置手工刷新模式
alter pluggable database xxx refresh mode manual;
--手工刷新，哪怕设置了自动刷新，也可以手动刷
alter pluggable database xxx  refresh;
--每小时刷一次
alter pluggable database xxx  refresh mode every 1 hours;

此步骤完成，可以正常刷新的话，后面没发现有什么坑。

1. 测试增量传输 可以在源库创建测试表，目标端以read only方式打开查看，测试是否能正常到目标库

--目标端操作
alter pluggable database xxx open read only instances=all;
alter session set container=xxx;
--检查测试数据传输后恢复到可刷新状态
 alter pluggable database xxx close immediate;
alter pluggable database xxx refresh mode every 10 minutes;

4.3 切换阶段

1. 应用侧关闭所有业务，期间可以手工刷新一次减少增量数据

alter pluggable database xxx refresh;

1. 源库操作：应用关闭后，一致性关闭源库，再以read only模式打开。（确保无新业务进来，job也不再运行）

alter pluggable database xxx close immediate instances=all; 
alter pluggable database xxx open read only instances=all;

1. 目标库最后一次刷新

alter pluggable database xxx refresh;

1. 激活目标库

--设置刷新模式为none（不可逆）
alter pluggable database xxx refresh mode none;

1. 打开目标库

alter pluggable database xxx open instances=all;

1. 执行datapatch

$ORACLE_HOME/OPatch/datapatch -pdbs xxx

1. 如果此时pdb为受限状态，需要重启pdb，两节点执行
2. 创建与源库同名service。PDB refresh完成需要自己创建服务

--oracle run
srvctl add service -d 实例名 -pdb pdb名 -s 服务名 -r 节点1sid,节点2sid  -P BASIC -y automatic -z 10 -w 10 -e select -m basic

1. 检查无问题通知网络专业，修改域名ip对应关系，或者提供新连接串给应用侧
2. 可以对比源库目标库对象数量，抽取关键表对比行数以及检查失效对象
3. 通知应用侧起应用测试

完成此步骤，迁移结束。

4.4 异常处理

如果应用测试有问题，则将源库关闭重新open，应用使用原先连接串即可。

4.5 时间消耗

实际切换用时20分钟，源库关闭执行检查点及目标库执行datapath稍微耗时多一点。

五、PDB Refresh如何读取增量数据？

首先读redo，没有的话读归档日志，已测试验证。 另外rac环境切换归档，需要使用alter system archive log current;如果用了alter system switch logfile会导致refresh失败。

六、小结

条件合适的情况下，使用PDB Refresh方式迁移PDB简单快捷，但是目前感觉坑多一点。