近期在某银行生产环境做的一次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<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;
此步骤完成,可以正常刷新的话,后面没发现有什么坑。
- 测试增量传输
可以在源库创建测试表,目标端以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简单快捷,但是目前感觉坑多一点。