Oracle 11g单库升级至19c单库(autoupgrade方式)
本案例使用autoupgrade方式完成数据库升级(autoupgrade工具将很多升级前后的工作都自动化完成,减少了大部分人工操作!)
案例使用autoupgrade版本为21.1.3
一、前提说明
1、案例环境
源数据库版本:11.2.0.4
升级后目标数据库版本:19.3.0.0
操作系统:linux7.9
源数据库ORACLE_HOME:/u01/app/oracle/product/11.2.0/db_1
目标数据库ORACLE_HOME:/u01/app/oracle/product/19.3.0/db_1
升级方式:dbua图形方式(dbua方式)
autoupgrade版本
[oracle@host51 ~]$ java -jar /u01/soft/autoupgrade.jar -version
build.hash 57ab246
build.version 21.1.3 //autoupgrade版本
build.date 2021/04/21 13:32:13
build.max_target_version 21
build.supported_target_versions 12.2,18,19,21 //可以升级到这些版本
build.type production
2、19C对操作系统支持最低要求为Linux7,如果11g的操作系统版本为Linux 6,则需要通过rman恢复方式,将源库恢复至一台新Linux7服务器上,并且在新主机安装19C软件。
3、如果升级后19C需要安装RU补丁集,可以在19c版本安装后(或者安装命令中加入-applyRU方式:./runInstaller -applyRU),提前将RU补丁集一起安装!!(升级工作之前!)
4、Oracle 19C只需要安装数据库软件(安装时选择仅安装数据库软件)!!用19c数据库软件升级11g数据库,升级成功后,就成为了一套19c版本的数据库。
5、直接升级至19c版本的路线
| 源数据库版本 | 目标数据库版本 |
|---|---|
| 11.2.0.4 and Higher | 19.x |
| 12.1.0.2 | 19.x |
| 12.2.0.1 | 19.x |
| 18.1 | 19.x |
6、间接升级至19c版本的路线
| 生成环境源数据库版本 | 过度升级版本 | 最终目标数据库版本 | ||
|---|---|---|---|---|
| 11.2.0.1/11.2.0.2/11.2.0.3 | 先升级至 | 11.2.0.4 | 最后升级至 | 19.x |
| 11.1.0.6/11.1.0.7 | 先升级至 | 11.2.0.4 | 最后升级至 | 19.x |
| 10.2.0.2, 10.2.0.3, 10.2.0.4, 10.2.0.5 | 先升级至 | 11.2.0.4/12.1.0.2 | 最后升级至 | 19.x |
| 10.1.0.5 | 先升级至 | 11.2.0.4/12.1.0.2 | 最后升级至 | 19.x |
| 9.2.0.8 or earlier | 先升级至 | 11.2.0.4 | 最后升级至 | 19.x |
| 12.1.0.1 | 先升级至 | 12.1.0.2/12.2.0.1 | 最后升级至 | 19.x |
7、COMPATIBLE初始化参数值要求
| Oracle数据库版本 | 默认值 | 最小值 |
|---|---|---|
| Oracle Database 19C | 19.0.0 | 11.2.0 |
| Oracle Database 12CR2 | 12.2.0 | 11.2.0 |
| Oracle Database 12CR1 | 12.0.0 | 11.0.0 |
| Oracle Database 11GR2 | 11.2.0 | 10.0.0 |
如果源Oracle上的compatible参数设置的值太低,无法升级到Oracle Database 19c,此时必须在源 Oracle Database 版本上设置至少满足Oracle Database 19c升级支持的最小值(11.2.0)。
例如:如果源Oracle Database版本是 Oracle Database release是11.2.0.4,但 compatible 参数是设置为10.0.0,则必须将compatible参数设置为至少支持升级的最小值(11.2.0),然后再升级。
SQL> alter system set compatible=‘11.2.0’ scope=spfile;
注意:更改参数后,必须重新启动数据库!
8、Oracle数据库安装
备注:
1)19c安装之前,需要给oracle用户新增的几个group组,如下
groupadd -g 2002 oper
groupadd -g 2003 backupdba
groupadd -g 2004 dgdba
groupadd -g 2005 kmdba
groupadd -g 2006 racdba
usermod -g oinstall -G dba,backupdba,dgdba,kmdba,racdba,oper oracle
2)19c数据库软件安装时,创建单独的.base_profile_19c环境变量文件(不要覆盖原有的11g版本环境变量文件!!)
类似如下
vi /home/oracle/.bash_profile_19c
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin
TMP=/tmp; export TMP
TMPDIR=$TMP; export TMPDIR
export ORACLE_SID=orcl
#export ORACLE_UNQNAME=orcl 如果计划安装EM时,必须先设置ORACLE_UNQNAME环境变量,不计划则可以不设置
#export CV_ASSUME_DISTID=OEL7.9 如果是Oracle Linux 版本需要添加改变量,其它操作系统不需要
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/19.3.0/db_1
export NLS_DATE_FORMAT="YYYY:MM:DDHH24:MI:SS"
export ORACLE_TERM=xterm
export PATH=$ORACLE_HOME/bin:/usr/sbin:$ORACLE_HOME/OPatch:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib:$ORACLE_HOME/network/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$ORACLE_HOME/network/jlib
export EDITOR=vim
export LANG=en_US.UTF-8
export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
stty erase ^H
3)安装19c时,使用.base_profile_19c环境变量文件
方法如下
su - oracle
source /home/oracle/.bash_profile_19c
验证
env|grep ORACLE
4)开始安装19c数据库软件
参考文章《Oracle 11g 单机安装总结_linux7》《Oracle 19c数据库软件和数据库静默安装》《Oracle 19c单机安装总结_linux7》《Oracle 11g软件和数据库静默安装》
9、强烈建议
1)升级前备份源数据库(rman物理方式或者expdp逻辑方式都行)
2)升级前将源库中的无效对象全部处理
3)升级前充分的测试和验证!!!
10、autoupgrade工具的核心命令
配置jdk变量
export PATH=$PATH:/u01/app/oracle/product/19.3.0/db_1/jdk/bin
编辑配置文件
java -jar /u01/soft/autoupgrade.jar -create_sample_file config
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode analyze
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode fixups
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode deploy
备注:
analyze、fixups、deploy会进入到升级的程序命令行界面。提示符是upg。
输入lsj查看job编号
upg> lsj
编号是从100开始计数的,再用命令查看这个编号的job的进度等详细信息:
upg> status -job 101 //查看job的具体工作内容、进度等详细信息
upg> logs -job 101 //查看日志
11、官网推荐升级前后的建议
引用MOS文档2577572.1(不涉及Windows平台)
1)推荐/需要在源库上完成的
1.1、对源库做备份(冷备份或热备份、逻辑备份都可以)
1.2、禁用所有自定义的 before/after DDL 类型的触发器,完成升级后再启用它们。
1.3、在 11g 中Oracle OLAP(数据安全)组件,Analytic Workspace(分析工作区)的权限通过 OLAPSYS 模式下的自定义数据库角色(Data Security Roles)来控制,而 19c 已全面改用新的 ORAS(OLAP Role-Based Access Security) 框架。这两个体系底层表结构完全不兼容,升级前必须手动删除旧角色,否则升级脚本遇到不兼容对象会直接报错中断,或导致升级后的对象全部处于 INVALID 状态且无法修复。(SELECT COUNT(*) FROM DBA_AW_ROLES;通过该语句查询是否启用了OLAPSYS 模式下的自定义数据库角色,查询无结果表示没有使用跳过该步骤即可)
1.4、检查目标数据库的 time zone 文件版本是否低于源库的 time zone 文件版本,如果是的话,需要升级目标数据库的time zone文件版本。 数据库 DST 补丁可以参考Note 412160.1(dbua方式会自动升级数据库时区版本,dbupgrade命令方式不会自动升级)
1.5、如果源库上已经安装了 APEX 组件,那么升级数据库前需要先在源库上升级 APEX 组件(或者先先卸载,后续再重装aplex组件),参考 Note 1088970.1
1.6、源库中没有失效的对象/组件
1.7、升级前执行 Preupgrade 脚本并检查 preupgrade 日志。
1.8、执行dbupgdiag.sql (可以从Note 556610.1下载这个脚本) 确认是否有 SYS/SYSTEM 用户下的失效对象或者失效组件。 如果存在的话, 那么需要在升级前解决这些问题。 可以多次执行 utlrp.sql 来解决问题。如果在这样做之后仍然存在失效对象,那么开一个SR来解决这个问题。
2)推荐/需要在目标库上完成的
2.1、安装数据库软件 19c(并应用最新的 RU), 并确保没有安装方面的问题。
2.2、从源库的 ORACLE_HOME/dbs 下拷贝 spfile 或者 pfile 到目标库(dbua方式会自动完成这些,dbupgrade命令方式不会)
2.3、从参数文件中删除所有废弃的参数
2.4、注意升级 19c 的 COMPATIBLE 参数的最小值为11.2.0, 确保您的 COMPATIBLE 参数设置为11.2.0或更高
2.5、查看文章 "Patches to apply before upgrading Oracle GI and DB to 19c (Doc ID 2539751.1)" 中给出的补丁建议,例如在目标库上应用 Patch 29213893 来避免已知问题。参考 Database Upgrade to 12.2, 18c, 19c fails with ORA-01422, ORA-06512 for SYS.DBMS_STATS (Doc ID 2525596.1)
二、升级前准备工作
1、数据库备份(自行完成)
2、设置11g和19c数据库软件的环境变量,用于后续升级工作(标识文件位置)
export ORACLE_HOME_11G=/u01/app/oracle/product/11.2.0/db_1
export ORACLE_HOME_19C=/u01/app/oracle/product/19.3.0/db_1
3、临时禁用所有自定义DDL语句(之前/之后)触发器。 升级后重新启用
1)查询所有 DDL 触发器(排查SYS和SYSTEM系统内置的)
su - oracle
sqlplus "/as sysdba"
SELECT OWNER, TRIGGER_NAME, STATUS
FROM DBA_TRIGGERS
WHERE TRIGGERING_EVENT LIKE '%DDL%' -- 关键过滤条件:只选DDL事件[reference:1][reference:2]
AND OWNER NOT IN ('SYS', 'SYSTEM');
2)生成禁用所有自定义DDL触发器的SQL脚本
SELECT 'ALTER TRIGGER ' || OWNER || '.' || TRIGGER_NAME || ' DISABLE;' AS disable_command
FROM DBA_TRIGGERS
WHERE TRIGGERING_EVENT LIKE '%DDL%'
AND OWNER NOT IN ('SYS', 'SYSTEM');
3)升级工作完成后,启用DDL触发器脚本
-- 生成启动所有自定义DDL触发器的SQL脚本
SELECT 'ALTER TRIGGER ' || OWNER || '.' || TRIGGER_NAME || ' ENABLE;' AS disable_command
FROM DBA_TRIGGERS
WHERE TRIGGERING_EVENT LIKE '%DDL%'
AND OWNER NOT IN ('SYS', 'SYSTEM');
4、检查无效对象和组件(**建议提前手工处理!!!**确保数据库组件和对象均为有效)
set linesize 200 pagesize 999
col comp_name format a40
col object_name format a40
col object_type format a40
col owner format a30
select substr(comp_name,1,40) comp_name, status, substr(version,1,10) version from dba_registry order by comp_name;
select substr(object_name,1,40) object_name,substr(owner,1,15) owner,object_type
from dba_objects where status='INVALID' order by owner,object_type;
select owner,object_type,count(*) from dba_objects where status='INVALID' group by owner,object_type order by owner,object_type ;
强烈建议升级前将源库中的无效对象全部处理(要么全部编译为有效状态,那些编译过后还是无效的对象,与业务人员核实,备份后删除掉)
备注:重新编译无效对象的方法如下
sqlplus / as sysdba
@?/rdbms/admin/utlrp.sql
备注:查看用户的无效对象另一种方法
SET SERVEROUTPUT ON;
EXECUTE DBMS_PREUP.INVALID_OBJECTS;
5、执行权限授予操作
XDB组件在升级过程中有时失效,且重新安装后升级依然失效,必须要执行如下权限授予操作
GRANT EXECUTE ON DBMS_LOB TO XDB;
GRANT EXECUTE ON UTL_FILE TO XDB;
6、APEX组件处理
如果数据库中已安装APEX,建议先升级源DB中的APEX,再升级DB。或者先删除掉APEX组件(删除组件后会有一个无效对象出现,对象 名SYS.HTMLDB_SYSTEM 类型PACKAGE BODY,不影响后续升级),升级完成后再重新安装
备注:从 Oracle 18c 开始,APEX 组件不再随数据库升级而自动升级,需要自己去官网下载与 19c 兼容的 APEX 新版本(例如 19.2 或更高版本)
1)查看当前APEX版本
SELECT comp_name,
status,
version
FROM dba_registry
WHERE comp_name = 'Oracle Application Express';
2)解压APEX包
cd /u01/soft
unzip -q apex_19.2.zip
chown -R oracle:oinstall /u01/soft
3)升级apex
cd /u01/soft/apex
sqlplus / as sysdba @apexins.sql SYSAUX SYSAUX TEMP /i/
备注/i/):这是一个虚拟目录,不是服务器上的真实物理路径。它代表了一个URL路径(例如 http://your_server/apex/i/),APEX 会通过这个路径来访问其静态资源文件。官方文档建议将其固定设置为 /i/,以方便未来升级
4)验证
SELECT comp_name,
status,
version
FROM dba_registry
WHERE comp_name = 'Oracle Application Express';
COMP_NAME STATUS VERSION
---------------------------------------- ---------------------- ------------------------------
Oracle Application Express VALID 19.2.0.00.18
5)编译无效对象(升级完aplex后,会出现很多无效对象,需要重新编译)
sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/utlrp.sql
备注:先删除掉APEX组件的方法!!
cd $ORACLE_HOME/apex
sqlplus "/as sysdba"
@apxremov.sql
7、检查数据库时区版本
备注:升级前数据库时区应小于或等于目标数据库时区版本,19C版本为32
检查方法
SELECT version FROM v$timezone_file;
结果
SQL> SELECT version FROM v$timezone_file;
VERSION
----------
14
8、在升级之前,停止源数据库中的物化视图
检查所有的物化视图的状态,刷新所有没有刷新的物化视图。
检查物化视图日志的大小,如果物化视图日志的行数非零,那么刷新物化视图。
检查物化视图
SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;
select owner, mview_name from all_mviews where staleness = 'STALE';
select owner, mview_name from all_mviews where staleness not in ('FRESH', 'STALE', 'UNKNOWN') or compile_state not in ('VALID');
9、临时禁用crontab计划任务(涉及数据库相关的任务)
crontab -e
10、检查COMPATIBLE参数
升级19C的COMPATIBLE参数的最小值为11.2.0,确保将COMPATIBLE参数设置为11.2.0或更高。
show parameter compatible
11.2.0.4.0 //符合要求,无需修改
11、检查当前有没有处于备份或者恢复的文件
SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
SELECT * FROM v$recover_file;
升级前,数据库中必须没有处于备份或者恢复的文件
12、清空回收站(建议提前手工处理!!!加速升级时执行速度)
PURGE DBA_RECYCLEBIN;
13、检查是否启用块跟踪功能(Block Change Tracking)
如果启用了 "Block Change Tracking" 功能,需要在升级前禁用它。
下面是具体的命令
检查是否启用
SELECT filename, status, bytes FROM v$block_change_tracking;
具体禁用命令
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
在升级前的源库执行上面的命令
在完成升级后再启用这个功能并在恢复增量备份前做一个0级备份。
升级前禁用块跟踪功能的意义:
避免兼容性问题:11g 的BCT文件格式或内容可能与 19c 不兼容,升级过程中直接读取旧格式文件可能导致错误甚至失败。
确保升级过程纯净:禁用BCT可以让升级程序专注于核心数据库文件的转换,排除这个外部因素的干扰。
14、升级前检查PUBLIC同义词AREA正确指向MDSYS.OGC_AREA
如果安装了 Oracle Multimedia 或者 Oracle Spatial组件,需要升级前检查 PUBLIC 同义词 AREA 正确指向 MDSYS.OGC_AREA。它应当被定义为 OGC_AREA 的同义词,否则会导致升级后Oracle Multimedia 或者 Oracle Spatial组件失效
select owner, synonym_name, table_owner, table_name from dba_synonyms where synonym_name = 'AREA';
查询应返回且仅返回一条记录,其中 TABLE_OWNER 为 MDSYS,TABLE_NAME 为 OGC_AREA。
如果查询无结果,或 TABLE_OWNER 与 TABLE_NAME 不是 MDSYS 和 OGC_AREA,则需要在升级前进行修复,具体修复如下。
删除错误的同义词(如果存在)
DROP PUBLIC SYNONYM AREA;
创建正确的同义词:
CREATE PUBLIC SYNONYM AREA FOR MDSYS.OGC_AREA;
再次验证
select owner, synonym_name, table_owner, table_name from dba_synonyms where synonym_name = 'AREA';
15、升级前密码状态为 EXPIRED(已过期)和账户状态为 LOCKED(已锁定)排查
19c会将一类特殊的账户自动转换为 Schema-Only(仅方案)账户,这类账户的特点是没有密码,无法直接登录数据库(DBA_USERS中的AUTHENTICATION_TYPE列会显示为NONE),让那些不再需要的默认账户(如DBSNMP、XDB等)自动变为无密码的Schema-Only状态,从而消除因默认密码带来的安全风险。
同时满足EXPIRED和LOCKED才会转换为Schema-Only账户
SYS和SYSTEM账户不受此机制影响,不会被自动转换
查询语句:
SELECT USERNAME, ACCOUNT_STATUS
FROM DBA_USERS
WHERE ACCOUNT_STATUS LIKE 'EXPIRED%' AND ACCOUNT_STATUS LIKE '%LOCKED%';
建议:如果这些内部账号,无需使用,直接让升级过后转变为Schema-Only账户即可,无需做任何动作!
如果需要使用,则只需将EXPIRED和LOCKED两个状态修改其中一个,就不会满足转换条件。例如ALTER USER username ACCOUNT UNLOCK;
当然升级后,转为Schema-Only的账号,后续只需重新设置密码,就可以重新获得密码登录的能力。
16、检查密码大小写不敏感的用户
Oracle10g及更早 版本中创建的账户,如果密码版本中只包含10G,说明这些账户的密码是大小写不敏感的。
Oracle11g 开始默认启用密码大小写敏感(SEC_CASE_SENSITIVE_LOGON=TRUE),但是可以两者共存。而进一步从 Oracle Database 12c release 2 (12.2) 开始,默认的基于密码验证的协议,排除了大小写不敏感的10g 版本的密码。默认的SQLNET.ORA文件中参数SQLNET.ALLOWED_LOGON_VERSION_SERVER被设置成了12 (排他模式)。
10g版本的密码(即PASSWORD_VERSIONS值为10G)升级到19c 后,这些账户可能会被自动锁定(LOCKED),导致应用无法登录。
PASSWORD_VERSIONS值 含义
10G 11G 同时支持大小写不敏感和敏感,安全
10G 仅支持大小写不敏感,需要处理
11G 或 12C 仅支持大小写敏感,安全
确定要升级的Oracle数据库是否存在使用了不区分大小写密码版本的帐户,查询语句如下:
SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;
如果存在 10G 版本的账户,处理方法有两种
方法一:重置密码
ALTER USER username IDENTIFIED BY new_password;
重置后,PASSWORD_VERSIONS 会更新为当前数据库版本(如 11G 12C),升级后不会被锁定。
方法二:升级前启用大小写不敏感模式(临时方案)
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
这只是一个临时方案,不推荐作为长期策略,因为会降低安全性。升级完成后建议重新启用。21C版本后,该参数已经弃用!!
17、设置和保留一个隐含参数_optimizer_cartesian_enabled,确保设置为TRUE
参数含义:控制优化器是否允许生成笛卡尔积的执行计划
在 11g 升级到 19c 的场景中,如果该参数被设置为 FALSE,可能会导致部分 SQL 执行计划在升级后发生变化,影响性能。
Oracle 官方建议在升级前将其设置为 TRUE,以匹配 19c 的默认行为
SELECT name,description from SYS.V$PARAMETER WHERE name LIKE '\_%' ESCAPE '\';
alter system set "_optimizer_cartesian_enabled"=TRUE;
18、如果数据库使用了 TDE(透明数据加密),需要复制Transparent Encryption Oracle钱包
在升级前手动将钱包文件(ewallet.p12)和配置文件(sqlnet.ora)复制到新的 Oracle 主目录
必须在实际执行数据库升级(如运行 dbupgrade 或 DBUA)之前完成。确保在升级过程中,19c 环境能够访问加密密钥!!!!
su - oracle
cp $ORACLE_HOME_11G/network/admin/sqlnet.ora $ORACLE_HOME_19C/network/admin/
cp $ORACLE_HOME_11G/network/admin/*wallet* $ORACLE_HOME_19C/network/admin/
具体步骤
在源(11g) 环境中找到钱包文件的位置。这通常在 $ORACLE_HOME/network/admin/sqlnet.ora文件中通过 ENCRYPTION_WALLET_LOCATION 参数定义。
在该参数指定的目录下,找到核心的钱包文件 ewallet.p12。如果启用了自动登录,还会有 cwallet.sso 文件。
将 sqlnet.ora 文件以及整个钱包目录(包含 ewallet.p12 等文件)复制到新(19c) Oracle 主目录下对应的 network/admin 目录中。
在 19c 环境中打开钱包
在新(19c) 的 Oracle 主目录环境下,启动数据库到 MOUNT 状态。
执行以下命令打开钱包,提示时输入钱包密码。
STARTUP MOUNT;
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "wallet_password";
备注:
1、如果你使用的是自动登录钱包(即有 cwallet.sso 文件),复制该文件后,钱包在实例启动时会自动打开,无需手动执行打开钱包的步骤。
2、关于 WALLET_ROOT (19c 新特性):19c 引入了 WALLET_ROOT 参数,官方推荐使用它来代替 sqlnet.ora 中的 ENCRYPTION_WALLET_LOCATION 配置钱包位置。你可以在升级完成之后,考虑将钱包迁移到 WALLET_ROOT 指定的位置,以采用更现代化的管理方式。
3、在 RAC 环境中,需要确保每个节点的 sqlnet.ora 文件和钱包文件都已正确复制,并且所有节点都能访问到钱包文件(通常放在共享存储上)
19、java环境变量设置
本案例使用的autoupgrade版本为21.1.3,需要 JDK 1.8 或更高版本才能运行。Oracle 11g自带的 JDK 1.5不满足要求,需要指定一个 19c 或更高版本 Oracle 主目录下的 JDK 路径
本案例autoupgrade工具存放位置/u01/soft
su - oracle
export PATH=$PATH:/u01/app/oracle/product/19.3.0/db_1/jdk/bin
JDK版本查询
[oracle@host51 bin]$ java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
autoupgrade版本查询
java -jar /u01/soft/autoupgrade.jar -version
[oracle@host51 ~]$ java -jar /u01/soft/autoupgrade.jar -version
build.hash 57ab246
build.version 21.1.3
build.date 2021/04/21 13:32:13
build.max_target_version 21
build.supported_target_versions 12.2,18,19,21
build.type production
20、autoupgrade工具的配置文件
生成一个样板配置文件
java -jar /u01/soft/autoupgrade.jar -create_sample_file config
命令输出如下
[oracle@host51 soft]$ java -jar /u01/soft/autoupgrade.jar -create_sample_file config
Created sample configuration file /u01/soft/sample_config.cfg
配置config.cfg文件
cp /u01/soft/sample_config.cfg /u01/soft/sample_config.cfg.bak
vi /u01/soft/sample_config.cfg
#全局日志路径
global.autoupg_log_dir=/tmp/autoupgrade_log
#日志目录
upg1.log_dir=/tmp/autoupgrade_log/orcl
#升级完成之后收集数据字典统计信息
global.dictionary_stats_after=yes
#升级之前收集数据字典统计信息
global.dictionary_stats_before=yes
#升级之前收集固定表统计信息
global.fixed_stats_before=yes
#创建闪回点
global.restoration=no ##不生成回复点GRP,需要设置闪回,默认是yes
#升级完成之后不删除闪回点,人工确认
global.drop_grp_after_upgrade=no
#升级数据库的数据库名
upg1.dbname=orcl
#升级的开始时间
upg1.start_time=NOW
#源端DB ORACLE_HOME
upg1.source_home=/u01/app/oracle/product/11.2.0/db_1
#源端DB ORACLE_HOME
upg1.target_home=/u01/app/oracle/product/19.3.0/db_1
#升级数据库的ORACLE_SID
upg1.sid=orcl
#升级节点的hostname
upg1.upgrade_node=host51
#升级之后执行对象编译
dbold.run_utlrp=yes
#升级之后,升级时区
dbold.timezone_upg=yes
#升级的目标版本19c
upg1.target_version=19
21、analyze(运行升级前的检查脚本)
该命令会生成一个报告,用于检查源数据库是否满足升级条件,并给出相关修改建议。
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode analyze
22、Fixups模式(运行升级前修复脚本)
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode fixups
23、将源库的tnsnames.ora复制到19c版本的对应目录下
cp $ORACLE_HOME_11G/network/admin/tnsnames.ora $ORACLE_HOME_19C/network/admin/
备注:autoupgrade工具会自动生成密码文件
24、停止监听(无需停库)
lsnrctl stop
至此,升级前准备工作完成!
三、开始升级
1、deploy模式升级
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode deploy
autoupgrade工具的核心命令
配置jdk变量
export PATH=$PATH:/u01/app/oracle/product/19.3.0/db_1/jdk/bin
编辑配置文件
java -jar /u01/soft/autoupgrade.jar -create_sample_file config
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode analyze
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode fixups
java -jar /u01/soft/autoupgrade.jar -config /u01/soft/sample_config.cfg -mode deploy
备注:
analyze、fixups、deploy会进入到升级的程序命令行界面。提示符是upg。
输入lsj查看job编号
upg> lsj
编号是从100开始计数的,再用命令查看这个编号的job的进度等详细信息:
upg> status -job 101 //查看job的具体工作内容、进度等详细信息
upg> logs -job 101 //查看日志
2、可选,删除还原点
sqlplus / as sysdba
select name from v$restore_point;
drop restore point xxxxx;//根据查询的结果删除还原点
exit;
3、检查和编译无效对象
检查
set linesize 200 pagesize 999
col comp_name format a40
col object_name format a40
col object_type format a40
col owner format a30
select substr(comp_name,1,40) comp_name, status, substr(version,1,10) version from dba_registry order by comp_name;
select substr(object_name,1,40) object_name,substr(owner,1,15) owner,object_type
from dba_objects where status='INVALID' order by owner,object_type;
select owner,object_type,count(*) from dba_objects where status='INVALID' group by owner,object_type order by owner,object_type ;
编译无效对象
sqlplus / as sysdba @?/rdbms/admin/utlrp.sql
4、删除原11g环境相关文件
##将19c的环境变量设置为默认的
mv /home/oracle/.bash_profile /home/oracle/.bash_profile_11g
mv /home/oracle/.bash_profile_19c /home/oracle/.bash_profile
##移除11g的HOME目录
mv /u01/app/oracle/product/11.2.0/db_1 /u01/app/oracle/product/11.2.0/db_1_bak2
source /home/oracle/.bash_profile
env|grep ORACLE
备注:
第一条命令将原有的环境变量修改为.bash_profile_11g
第二条命令将19c环境变量修改为正式的.bash_profile
第三条命令将源有的数据库HOME目录mv或者删除都行
第四条命令使得.bash_profile环境变量文件生效
第五条命令验证.bash_profile环境变量文件
5、配置sqlnet.ora
cat >>$ORACLE_HOME/network/admin/sqlnet.ora <<EOF
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
EOF
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8: 告诉数据库服务器,允许最低版本为8的客户端进行连接。
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8: 当数据库作为客户端连接其他数据库时,允许使用最低版本为8的协议。
为了让升级后的19c数据库能兼容非常老的客户端(如8i、9i、10g等),否则老客户端连接数据库报ORA-28040: No matching authentication protocol
19c版本后,两个参数的默认值为12,导致老的一些老客户端无法连接。(向下兼容)
6、执行$ORACLE_HOME/rdbms/admin/utldirsymlink.sql脚本
备注:Oracle 出于安全考虑,不允许数据库中的目录对象(Directory Object)指向操作系统层面包含符号链接(Symbolic Link)的路径,因为这可能被利用进行路径遍历攻击
@?/rdbms/admin/utldirsymlink.sql
脚本执行后,会生成一个输出报告,列出所有当前路径中包含符号链接的目录对象名称及其指向的操作系统路径。
解决方法
1)根据获得包含符号链接的目录对象名称及其指向的操作系统路径
2)使用 readlink -f 解析真实路径:
readlink -f /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/log
3)得到真实路径后(例如 /u01/app/oracle/product/11.2.0.4/dbhome_1/rdbms/log),记录下来。
4)重新创建目录对象(消除软链接)
5)使用解析出的真实物理路径,重新创建(覆盖)这些目录对象。类似如下
CREATE OR REPLACE DIRECTORY DATA_PUMP_DIR AS '/u01/app/oracle/product/11.2.0.4/dbhome_1/rdbms/log';
7、SYS,SYSTEM用户状态查询,如果为OPEN状态表示正常,其它状态可能需要手工处理
检查状态
SELECT USERNAME,ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME IN ('SYS','SYSTEM');
USERNAME ACCOUNT_STATUS
--------------------------- --------------------------------
SYSTEM OPEN --表示正常,后续修改状态和重置密码动作无需执行
SYS OPEN --表示正常,后续修改状态和重置密码动作无需执行
如果查询结果为下面的状态,则需要修改状态和重置密码
SQL> SELECT USERNAME,ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME IN ('SYS','SYSTEM');
USERNAME ACCOUNT_STATUS
---------------------------------------------------------------------------------------
SYSTEM EXPIRED & LOCKED --异常,需要修改状态和重置密码
SYS LOCKED --异常,需要修改状态和重置密码
修改状态和重置密码的方法类似如下(只是记录,大多数情况无需执行这些)
UPDATE USER$ SET ASTATUS=0 WHERE NAME='SYS';
UPDATE USER$ SET ASTATUS=0 WHERE NAME='SYSTEM';
COMMIT;
alter system flush shared_pool;
alter user system identified by Oracle11__;
alter user sys identified by Oracle11__;
8、修改COMPATIBLE参数
ALTER SYSTEM SET COMPATIBLE="19.0.0" SCOPE=SPFILE;
9、重启数据库
shutdown immediate
startup
10、启动19c版本的监听
su - oracle
lsnrctl start
11、启用crontab
crontab -e
12、升级工作完成后,启用DDL before和after触发器脚本
-- 生成启动所有自定义DDL触发器的SQL脚本
SELECT 'ALTER TRIGGER ' || OWNER || '.' || TRIGGER_NAME || ' ENABLE;' AS disable_command
FROM DBA_TRIGGERS
WHERE TRIGGERING_EVENT LIKE '%DDL%'
AND OWNER NOT IN ('SYS', 'SYSTEM');
13、生成新的密码文件(可选)
[oracle@hellodba ~]$ cd $ORACLE_HOME/dbs
[oracle@hellodba dbs]$ mv orapwhellodb orapwhellodb_bak
[oracle@hellodba dbs]$ orapwd file=orapworcl entries=5
Enter password for SYS: Oracle11__
19c密码文件的安全性加强,密码复杂度需要满足一定要求才行!!!
14、业务测试
四、升级总结
1、APEX组件中三个PACKAGE BODY对象失效问题处理
参考前面的文章《Oracle 11g单库升级至19c单库(一)》
2、21.1.3版本的autoupgrade,自动修复的内容如下(可以看到很多工具都可以自动完成修复!!)
[root@host51 ~]# more /tmp/autoupgrade_log/orcl/orcl/100/prechecks/orcl_preupgrade.log
Report generated by AutoUpgrade 21.1.3 (#57ab246) on 2026-07-06 14:48:27
Upgrade-To version: 19.0.0.0.0
......
......
==============
BEFORE UPGRADE
==============
REQUIRED ACTIONS
================
None
RECOMMENDED ACTIONS
===================
1. (AUTOFIXUP) Remove OLAP Catalog by running the 11.2.0.4.0 SQL script
//自动完成
2. (AUTOFIXUP) Remove the EM repository.
//自动完成
3. (AUTOFIXUP) Update NUMERIC INITIALIZATION PARAMETERS to meet estimated
minimums. This action may be done now or when starting the database in
upgrade mode using the 19 ORACLE HOME.
Parameter Currently 19 minimum
--------- --------- ------------------
processes 150 300
//自动完成
4. Upgrade Oracle Application Express (APEX) manually before or after the
database upgrade.
//APEX组件需要手工升级
5. (AUTOFIXUP) Gather stale data dictionary statistics prior to database
upgrade in off-peak time using:
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
//自动完成统计信息手机
6. (AUTOFIXUP) Directly grant ADMINISTER DATABASE TRIGGER privilege to the
owner of the trigger or drop and re-create the trigger with a user that
was granted directly with such. You can list those triggers using: SELECT
OWNER, TRIGGER_NAME FROM DBA_TRIGGERS WHERE
TRIM(BASE_OBJECT_TYPE)='DATABASE' AND OWNER NOT IN (SELECT GRANTEE FROM
DBA_SYS_PRIVS WHERE PRIVILEGE='ADMINISTER DATABASE TRIGGER').
//自动完成
7. (AUTOFIXUP) Gather statistics on fixed objects prior to the upgrade using
the command:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
//自动完成
INFORMATION ONLY
================
8. (AUTOFIXUP) Run $ORACLE_HOME/rdbms/admin/catnoexf.sql located in the new
Oracle Database Oracle home to remove both EXF and RUL.
Expression Filter (EXF) or Rules Manager (RUL) exist in the database.
//自动完成
9. Check the Oracle documentation for the identified components for their
specific upgrade procedure.
The database upgrade script will not upgrade the following Oracle
components: AMD, APEX, OWB
//AMD, APEX, OWB组件需要手工完成升级
10. (AUTOFIXUP) Mandatory changes are applied automatically in the
during_upgrade_pfile_dbname.ora file. Some of these changes maybe present
in the after_upgrade_pfile_dbname.ora file. The
during_upgrade_pfile_dbname.ora is used to start the database in upgrade
mode. The after_upgrade_pfile_dbname.ora is used to start the database
once the upgrade has completed successfully.
Parameter
---------
cluster_database='FALSE'
//自动完成
11. Check the Oracle Backup and Recovery User's Guide for information on how
to manage an RMAN recovery catalog schema.
12. To help you keep track of your tablespace allocations, the following
AUTOEXTEND tablespaces are expected to successfully EXTEND during the
upgrade process.
13. Follow the instructions in the Oracle Multimedia README.txt file in <19
ORACLE_HOME>/ord/im/admin/README.txt, or MOS note 2555923.1 to determine
if Oracle Multimedia is being used. If Oracle Multimedia is being used,
refer to MOS note 2347372.1 for suggestions on replacing Oracle
Multimedia.
14. Here are ALL the components in this database registry:
......
15. Here is a count of invalid objects by users:
User Name Number of INVALID Objects
--------------------------- -------------------------
None None
Review the information before upgrading.
=============
AFTER UPGRADE
=============
REQUIRED ACTIONS
================
None
RECOMMENDED ACTIONS
===================
16. (AUTOFIXUP) Upgrade the database time zone file using the DBMS_DST
package.
//自动完成时区升级
17. (AUTOFIXUP) Recompile the objects with timestamp mismatch. Please refer to
MOS note 781959.1 for more details.
//自动完成无效对象编译
18. (AUTOFIXUP) Gather dictionary statistics after the upgrade using the
command:
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
//自动完成数据字典统计信息手机
19. Gather statistics on fixed objects after the upgrade and when there is a
representative workload on the system using the command:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
//可选项
20. (AUTOFIXUP) Run @?/rdbms/admin/utlrp.sql in order to recompile any invalid
objects.
//自动完成无效对象编译




