实施背景
今年春节加班期间, 将某客户的核心数据库从 Oracle 10.2.0.4 RAC 迁移升级至 12.2 RAC 原库是使用的 Raw, 而且版本较低, 无法直接升级到 12.2 版本, 因此整个升级过程相对麻烦
实施思路
我们在新环境部署了 10g11.212.2 的 Database 软件 (其中 10g,11.2 均为单机, 12.2 为已经安装好的 Oracle RAC 环境);
然后配置好主库到新环境的 DataGuard 数据同步, 在正式割接之前确认主备同步正常由于需要将数据库从 10gR2 迁移到新环境并且升级到 12.2, 且需要使用 CDB 模式, 因此整个过程相对繁琐
如下是大致步骤:
停止 Job(将 job_queue_processes 参数提前置为 0, 并 kill 相关进程);
检查分布式事务, 并进行相关处理 (实际上我们检查确实发现了部分分布式事务需要手工介入);
- select 'exec DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('||chr(39)||LOCAL_TRAN_ID||chr(39)||');'||chr(10)||'commit;'
- from dba_2pc_pending;
在确认主备数据同步之后, 进行 switchover, 如下是主备切换简约步骤:
-- 主库
- alter database commit to switchover to physical standby WITH SESSION SHUTDOWN;
- startup mount;
- alter database open read only;
-- 备库
- alter database commit to switchover to primary;
- startup force
新主库升级到 11.2 之前需要先创建还原点, 防止有问题可以回退;
- alter database flashback on;
- alter database open;
- alter system switch logfile;
- create restore point restore_point_10g guarantee flashback database;
执行升级脚本, 将数据库升级到 11.2;
确认升级成功之后, drop 还原点并创建新的还原点, 准备将数据库升级到 12.2;
- drop restore point restore_point_10g;
- create restore point restore_point_11g guarantee flashback database;
这里需要注意的是, 在升级到 12.2 之前需要将实例参数 compatible 设置为 11.2.0.4, 否则在升级过程中可能会遭遇 ORA-00600 错误
执行升级脚本将数据库升级到 12.2;
- @/home/oracle/shell/log/preupgrade_fixups.sql
- $ORACLE_HOME/perl/bin/perl -I $ORACLE_HOME/perl/lib $ORACLE_HOME/rdbms/admin/catctl.pl -n 8 $ORACLE_HOME/rdbms/admin/catupgrd.sql
- @/home/oracle/shell/log/postupgrade_fixups.sql
确认升级后数据库组件正常且无相关报错之后, drop 还原点;
- select comp_name,VERSION,STATUS from dba_registry;
- drop restore point restore_point_11g;
数据库升级到 12.2 之后, 需要将 DB 从 NO-CDB 模式转换成 CDB 模式, 将数据库作为 PDB 插入到 12.2 RAC 集群中;
如下是转 CDB 模式是相关简单步骤:
1) 启动实例到只读模式
- startup mount exclusive;
- alter database open read only;
2) 创建 xml 元数据文件
EXEC DBMS_PDB.DESCRIBE( pdb_descr_file => '/tmp/XXXDB.xml');
3) 检查兼容性
- DECLARE
- compatible CONSTANT VARCHAR2(3) :=
- CASE
- DBMS_PDB.CHECK_PLUG_COMPATIBILITY(pdb_descr_file => '/tmp/XXDB.xml',pdb_name => 'xxdb')
- WHEN TRUE THEN 'YES'
- ELSE 'NO'
- END;
- BEGIN
- DBMS_OUTPUT.PUT_LINE(compatible);
- END;
- /
4) 进行 nocopy 操作
CREATE PLUGGABLE DATABASE pdbcdrs USING '/tmp/XXDB.xml' NOCOPY;
5) 启动 PDB 进行并进行转换
- alter session set container= pdbcdrs;
- alter pluggable database pdbcdrs open;
- shutdown immediate;
- @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
创建 RedoUndo 以及修改相应参数, 将数据库转成 RAC 实例
问题讨论
在整个升级过程中, 我们遇到了几个小问题, 分别如下:
DataGuard 的文件 convert 参数没有加入 tempfile, 导致 DG 切换之后, 主库 open 有问题, 需要先 drop tempfile 之后才行;
在升级到 12.2 的过程中, 遇到 ORA-01722 错误, 如下所示:
根据 Oracle Mos 文档 Upgrade to 12.2 Fails with Error:ORA-01722: Invalid number : NONUPGRADED_TABLEDATA (文档 ID 2279497.1) 的描述, 可以通过如下的方式来解决:
- set serveroutput on
- @?/rdbms/admin/catuptabdata.sql
- @?/rdbms/admin/utluptabdata.sql
- execute dbms_preup.run_fixup_and_report('INVALID_SYS_TABLEDATA');
- execute dbms_preup.run_fixup_and_report('INVALID_USR_TABLEDATA');
- set serveroutput off
将数据库作为 PDB 插入到 CDB 之后, 打开 PDB 时提示为受限模式
该问题经查是由于我们在执行的过程中漏掉了一个步骤 (exec dbms_pdb.sync_pdb();), 导致 PDB 的信息与 CDB 的信息不一致, 本质上组件信息不一致
实际上从 Oracle 官方的解释来看, 只要 PDB 的组件属于 CDB 的子集就行, 我们当时查询结果却是显示正常的, 但是 PDB 的组件状态显示异常, 因此让 Oracle 认为 PDB 的组件与 CDB 有巨大差异, 将 PDB 置于受限模式 OPTION WARNING Database option mismatch: PDB installed version NULL in PDB_PLUG_IN_VIOLATIONS(文档 ID 2020172.1)
该文档中有详细的描述, 认为这是 12.2 的一个加强
- Some warnings in PDB_PLUG_IN_VIOLATIONS prevent you from actually opening the PDB in READ WRITE mode; this is not one of them. You can ignore these messages. It is okay for a PDB to have a subset (fewer) options installed than the CDB into which it is plugged.
- (The reverse is NOT true, however -- the CDB must always have the same or more options as its PDBs).
- Unpublished Bug 16192980 : NO SIMPLE WAY TO CLEAN ROWS FROM PDB_PLUG_IN_VIOLATIONS AFTER DBMS_PDB CALL has been filed to request a way to clear out no-impact warnings from PDB_PLUG_IN_VIOLATIONS. This enhancement is implemented in versions > 12.2.0.1.
我们尝试过将组件 Reinstall 然后再 Install 是可以的, 但是组件较多, 大约 8 个组件, 尤其是 Java 或 xdb 相关组件比较麻烦, 因此我们将 PDB 删除然后重新创建了 PDB 进行加载, 最终解决了该问题
来源: https://yq.aliyun.com/articles/499210