背景前言：
原环境为11202的windows环境，数据量较大约20T
目标环境为12201的linux环境
使用linux和windows的数据文件互通原理，原库关库拷贝数据文件后，在目标端启动并升级
升级流程：
- 启动实例到mount
- 注册拷贝的数据文件，switch to copy
- 修改redolog的路径
- Open upgrade
- 跑升级脚本
- 重启实例完成流程
启动实例
参数文件需要重新配置，以下有几个关键点
- 控制文件路径，与上传的控制文件路径相同
- Compatible参数值，要设置与软件同版本12.2.0.1
- Adump路径可用
- Sga_target，主机120g内存，设置到50g
- Db_name，与原库保持相同，protect
转换数据文件路径
| Rman target / Catalog start with ‘/data/protect/’; --将所有数据文件注册，新注册的数据文件被认为是copy Switch database to copy; --将copy数据文件转正 |
日志文件路径处理
| Alter database rename file ‘D:\windows\directory\REDO01.log’ to ‘/data/ABC/REDO01.log’; |
尝试以上失败
遂采用重建控制文件的形式解决路径问题
| Alter database backup controlfile to trace as ‘/data/oracle/ctl.txt’ |
截取ctl.txt中noresetlog+noarchivelog组合,并修改redo名,命名为ctl2.txt
| Startup nomount force @/data/ctl2.txt |
Scn号不平问题
Alter database open upgrade时看到有部分数据文件需要media recovery
从以下sql判断下数据文件不平的情况
| Select checkpoint_change#.count(*) from v$datafile_header; |
500多个数据文件中约25个为另一个较为旧的scn号
咨询了客户这个库关库的情况，说是正常关库
有可能是shutdown down的刷新scn号没有全部落盘，scn的落后的均是非system的数据文件，强起流程损坏不大。遂使用参数启动
- 配置参数allow_resetlogs_corruption=true
- 重建控制文件,使用resetlog+noarchivelog
- 启动数据库使用Alter database open resetlogs upgrade;
升级中遇到ORA-20001: Latest xml inventory is not loaded into table
跑@?/rdbms/admin/catupgrd.sql
提示升级脚本变化
使用以上命令升级
| $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql |
升级中抛出错误
ORA-20001: Latest xml inventory is not loaded into table
该错误较为复杂，是datapatch相关的视图失败
采用了以下办法
- export LANG=en_US.UTF-8
--无效操作
- 处理了/etc/oraInst.loc的空白
--无效操作，使用opatch lsinv可以输出inventory的信息，与inventory的连接正常
- 使用datapatch -verbose复现了错误，最终排查到时tempfile没有导致
日志中的核心错误为以下sql的执行返回问题
| select dbms_sqlpatch.verify_queryable_inventory from dual; ORA-20001: Latest xml inventory is not loaded into table |
根据文档2172655.1的提示
查询相关基表
| select * from OPATCH_XML_INV ; |
问题得到准确定位，应该是重建控制文件导致的临时文件丢失，重新添加临时文件
Alter tablespace temp add tempfile ‘/data/protect/temp01.dbf’ size 1g autoextend on;
Datapatch -verbose 输出正常
重新调用
| $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql |
升级成功
