近期在某银行生产环境做的一次PDB迁移,使用的是PDB refresh方式,记录一下流程及遇到的坑。
推荐视频:经典知识库:Oracle PDB Refresh实战分享 - 李海清
上述视频详细介绍了什么是PDB Refresh、使用场景、迁移流程,本文流程也是依照该视频为主要参考,推荐学习。
一、源库及目标库情况
源库与目标库情况:
源库 | 目标库 | |
---|---|---|
系统版本 | REHL 7.6 | RHEL 7.6 |
数据库版本 | 19.11 | 19.11 |
数据量 | 7 T | |
停机时间 | 2 hour |
二、迁移方式选择
根据以上的情况,认为DG与PDB refresh方式是比较好的选择。
- DG相较于PDB refresh配置更麻烦
- PDB refresh的前置条件比DG多
- 停机时间来看,DG略短于PDB refresh
最后还是定的使用PDB refresh,主要是因为没在生产上做过,积累下经验,另外也简单:)
三、什么是PDB Refresh
简单来说:创建目标端到源端的DBlink,目标端create pluggable database,指向源端PDB,这样就将源端PDB copy过来,copy过程源端无需停机,再设置refresh刷新,可以将源库的增量也应用到目标端。切换时源端read only,目标端read write,完事。
注意:
- PDB Refresh支持三种类型的源端数据库,分别是 Local PDB/PDB in a remote CDB/Non-CDB
- PDB Refresh不支持跨平台、不支持跨大版本
四、迁移流程
4.1 准备阶段
- 数据库版本。源库的版本不能大于目标端,可以同版本迁移或从低版本迁移到高版本,不支持高版本到低版本
sqlplus -v
- 源端和目标端数据库必须为归档模式。源端和目标端数据库必须为归档模式
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)
- 字符集。源库pdb的字符集要和目标CDB的字符集和国家字符集兼容,例如目标库是AL32UTF8的话,源库可以是ZHS16GBK,但是反过来就不行
select userenv('language') from dual;
- 字节序。源库目标库需要相同
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;
- 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)
- 数据库组件。目标库的组件要与源库一致,或者包含源库的组件,如果源库安装的组件比目标库多,需要在源库PDB下先删掉多出的组件,删除方式参考文章开头的推荐链接查看。这也是个坑,务必提前检查
select comp_id from dba_registry where status!='REMOVED';
- 确保目标库库CDB有足够的剩余SGA/PGA内存分配给refresh PDB;
- 确保目标库磁盘组有足够的剩余可用空间(数据文件物理空间)存放迁移过去的PDB并有适量余量。
- 如果目标cdb中存在users表空间,且被其他c##用户使用着,需要在源pdb预先创建users表空间。
- 源库目标库检查OMF是否启用,没启用的话,克隆时需要指定filel_name_convert参数
show parameter db_create_file_dest
11.另外参考视频中还提到:源库pdb中可能存在目标库cdb中没有的c##用户。需要进行删除操作。 生产环境不太适合删除,我是在目标库创建相同账户处理。
4.2 同步阶段
- 源库创建container用户
create user C##hf_refresh identified by Password123 container=all;
grant create session,sysoper,create pluggable database to c##hf_refresh container=all;
- 目标库创建dblink连接到源库CDB
create public database link hf_refresh_dblink connect to c##hf_refresh identified by Password123 using '10.9.xxx.xx:1521/RAP010';
- 目标端创建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
关于刷新方式:
代码语言:javascript复制--设置手工刷新模式
alter pluggable database xxx refresh mode manual;
--手工刷新,哪怕设置了自动刷新,也可以手动刷
alter pluggable database xxx refresh;
--每小时刷一次
alter pluggable database xxx refresh mode every 1 hours;
此步骤完成,可以正常刷新的话,后面没发现有什么坑。
- 测试增量传输 可以在源库创建测试表,目标端以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 切换阶段
- 应用侧关闭所有业务,期间可以手工刷新一次减少增量数据
alter pluggable database xxx refresh;
- 源库操作:应用关闭后,一致性关闭源库,再以read only模式打开。(确保无新业务进来,job也不再运行)
alter pluggable database xxx close immediate instances=all;
alter pluggable database xxx open read only instances=all;
- 目标库最后一次刷新
alter pluggable database xxx refresh;
- 激活目标库
--设置刷新模式为none(不可逆)
alter pluggable database xxx refresh mode none;
- 打开目标库
alter pluggable database xxx open instances=all;
- 执行datapatch
$ORACLE_HOME/OPatch/datapatch -pdbs xxx
- 如果此时pdb为受限状态,需要重启pdb,两节点执行
- 创建与源库同名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
- 检查无问题通知网络专业,修改域名ip对应关系,或者提供新连接串给应用侧
- 可以对比源库目标库对象数量,抽取关键表对比行数以及检查失效对象
- 通知应用侧起应用测试
完成此步骤,迁移结束。
4.4 异常处理
如果应用测试有问题,则将源库关闭重新open,应用使用原先连接串即可。
4.5 时间消耗
实际切换用时20分钟,源库关闭执行检查点及目标库执行datapath稍微耗时多一点。
五、PDB Refresh如何读取增量数据?
首先读redo,没有的话读归档日志,已测试验证。 另外rac环境切换归档,需要使用alter system archive log current;如果用了alter system switch logfile会导致refresh失败。
六、小结
条件合适的情况下,使用PDB Refresh方式迁移PDB简单快捷,但是目前感觉坑多一点。