从Oracle的12.1或12.2版本升级到最新的19c版本，目前可供选择的几种升级方案有：
1.插拔式升级，通用性好，属于数据迁移式的升级方式，不能整库进行升级，数据量越大耗时越长，业务中断时间长。
2.可刷新PDB升级，12.2版本开始支持，业务中断时间短，属于数据迁移式的升级方式，不能整库进行升级。
3.数据泵导出导入的方式升级，属于数据迁移式的升级方式，业务中断时长根据迁移数据量而定。
4.dbua整库升级，原地升级，升级期间影响所有PDB的业务可用性，业务中断时间长。
5.利用dbms_rolling包滚动升级，业务中断时间短，但是只从12.1.0.2版本开始支持，并且需要搭建ADG环境进行配合升级。
大型IT系统具有数据量大、服务连续性要求高的特点，所以安全高效的升级模式往往成为升级的首选。三墩IT人今天介绍的是利用12c版本才提供的dbms_rolling包进行滚动升级的测试。
Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING
功能介绍：
在12c版本之前，利用Logical Data Guard进行数据库的升级需要手动执行数十步的操作步骤，升级繁琐复杂度高容易带来很多的人为失误。为此，12c提供了新的PL/SQL(dbms_rolling)包和DDL命令来代替之前的手动执行的操作步骤，为ADG进行滚动升级提供了一种平滑的执行滚动升级的方法。这个过程开始前主库和物理备库是相同版本，执行结束后主库和备库同样是相同的新版本。这个自动化的过程包括升级到新版本过程中的切换操作，每一步的校验工作。如果在升级过程中出现问题，可以选择修正错误，重新执行升级工作，或者回滚到最初的数据库状态。
升级限制条件：
» 不支持原地替换升级
» 升级前后软件所有者用户相同
» ASM及CLUSTER需运行在相同的HOME下
» 确保$ORACLE_HOME/OPatch目录存在
» 升级过程命令不可用(srvctl,crsctl等)
» 若调整主备库角色，需滚动升级完成后进行
» OCR及VOTEDISK需放置在ASM中，不可放置在文件系统或裸设备
» 数据库兼容性版本12.1.0.2及以上
» 主备库必须开启归档，强制日志及闪回数据库
» 滚动升级过程，DG broker若已配置必须禁用（12.2.0.1开始无需禁用）
» ADG保护模式必须为最大性能或最大可用两者择一
逻辑备库同步限制：
ADG配合DBMS_ROLLING滚动升级过程中，物理备库会临时转变为逻辑备库，基于逻辑备库的数据同步，存在支持同步数据类型和操作的限制，具体限制请见文档：
Data Type and DDL Support on a Logical Standby Database
【相关网址：https://docs.oracle.com/】
下面介绍由12.1.0.2版本升级到18c的测试过程和测试结果：
测试环境：
12.1.0.2GI+DB 升级为18c GI+DB
测试过程：
升级GI过程
升级GI过程与其他版本大同小异，这里只提一下注意事项。
1）12.1.0.2升级到18C必须先安装补丁21255373。
若不安装上述补丁，安装过程预检查不通过：
2）18c环境下的GRID,对MGMTDB空间有一定要求，建议100G以上。若空间太小，安装过程会触发如下报错。
为规范后期MGMTDB管理，建议创建单独磁盘组进行存放。
DB升级过程：
数据库滚动升级预检查
1.部署18C数据库软件
2.ADG环境状态状态检查
3.主备库开启归档，强制日志及闪回闪回数据库功能
通过DBMS_ROLLING包执行滚动升级
1.滚动升级计划初始化
主库执行
EXEC DBMS_ROLLING.INIT_PLAN(future_primary=>'DB12C_STD');
/*future_primary参数值为目标备库DB_UNIQUE_NAME名称*/
参数检查
select scope, name, curval from dba_rolling_parameters order by scope,name;
2.创建滚动升级计划
主库执行
EXEC DBMS_ROLLING.BUILD_PLAN;
查看滚动升级计划
SELECT instid, target, phase, deion FROM DBA_ROLLING_PLAN order by 1;
告警信息查看
select EVENT_TIME,TYPE,MESSAGE,STATUS,INSTID,REVISION FROM DBA_ROLLING_EVENTS;
3．执行滚动升级
前提条件：
(1)备库需要在mount状态下，且处于recover状态;
(2)打开所有PDB[主库];
(3)主备闪回数据库功能要打开；
主库执行
EXECUTE DBMS_ROLLING.START_PLAN; /* 此命令结束后，备库由物理备库转变为逻辑备库，可读写 */
状态查看
-------------------------------------------------------------------------------
select revision,status,phase from dba_rolling_status;
select * from dba_rolling_statistics;
select
dbid,rdbid,dbun,role,open_mode,engine_status,version,update_progress,to_char(update_time,'yyyy-mm-dd hh24:mi:ss') "update_time" from dba_rolling_databases;
4.备库执行数据库升级
本文档为通过命令行方式进行数据库升级
(1)升级检查
$ORACLE_HOME/jdk/bin/java -jar /u01/app/oracle/product/18.0.0/dbhome_1/rdbms/admin/preupgrade.jar
(2)通过新版本数据库软件重启数据库为upgrade
若备库是RAC环境，修改CLUSTER_DATABASE参数为FALSE并重启数据
SQL*Plus: Release 18.0.0.0.0 - Production on Tue Aug 7 18:15:53 2018
Version 18.3.0.0.0
Copyright (c) 1982, 2018, Oracle. All rights reserved.
Connected to an idle instance.
SYS@DB12C1:SQL> startup upgrade
SYS@DB12C1:SQL> alter pluggable database all open upgrade;
Pluggable database altered.
到新版本数据库如下目录：
cd $NEW_ORACLE_HOME/bin
执行数据库升级：
./dbupgrade -M -n 48 -N 4
日志如下：
-----------------------
Argument list for [/u01/app/oracle/product/18.0.0/dbhome_1/rdbms/admin/catctl.pl]
Run in c = 0
Do not run in C = 0
Input Directory d = 0
··················
··················
Upgrade Summary Report Located in:
/u01/app/oracle/product/18.0.0/dbhome_1/cfgtoollogs/DB12C_STD/upgrade20180807182002/upg_summary.log
Grand Total Upgrade Time: [0d:1h:5m:21s]
正常重启数据库[高版本]
SQL> shudown immediate
$ sqlplus / as sysdba
SQL> alter pluggable database all open;
(3)编辑无效对象
export NEW_ORACLE_HOME=/u01/app/oracle/product/18.0.0/dbhome_1
$NEW_ORACLE_HOME/perl/bin/perl $NEW_ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b utlrp -d '''.''' /u01/app/oracle/product/18.0.0/dbhome_1/rdbms/admin/utlrp.sql
(4)升级后修复BUG
$NEW_ORACLE_HOME/perl/bin/perl $NEW_ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b postupgrade_fixups -d '''.''' /u01/app/oracle/cfgtoollogs/DB12C_STD/preupgrade/postupgrade_fixups.sql
(5)验证修复结果
$NEW_ORACLE_HOME/perl/bin/perl $NEW_ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b utlu122s -d '''.''' /u01/app/oracle/product/18.0.0/dbhome_1/rdbms/admin/utlu122s.sql
(6)升级数据库在集群中的信息
[新版本bin下执行srvctl]
$ srvctl upgrade database -db db-unique-name -oraclehome oraclehome
srvctl upgrade database -db PROD -oraclehome /u01/app/oracle/product/18.0.0/dbhome_1
5.完成主备库监听及TNSNAMES相关升级配置
针对手动配置的监听，分别把如下文件移动到新版本数据目录下
LISTENER.ORA
TNSNAMES.ORA
6．执行角色切换
主库执行
EXECUTE DBMS_ROLLING.SWITCHOVER; /* 切换后原主库转变为逻辑备库，备库转变为主库 */
切换后角色及状态查看：
7.原主库手动重启[新版本]
调整环境变量指向新版本数据库目录，重启数据库到mount状态
8.完成滚动升级
EXECUTE DBMS_ROLLING.FINISH_PLAN; /* 上述命令执行成功后，原主库由逻辑备库转变为物理备库 */
测试小结：
从本次测试可以看到实际执行的步骤比起11g使用逻辑备库升级方式有着明显的简化，升级过程中数据库的停服时间也从数小时减少至10分钟以内（仅为主备切换的过程），大大减少了业务中断时间，而且滚动升级的方式更加平滑安全并易于回退。此特性有可能会成为12.1.0.2以及以上版本升级到18C的首选方案。
所谓工欲善其事，必先利其器，Oracle整合后的dbms_rolling包所带来的便利性相信会更广泛的应用到生产中，但需要重视的是逻辑备库应用sql的限制，建议升级前做好全面的检查以及逻辑备库同步的演练。