本文由 dbaplus 社群授权转载。
大家好，今天咱来实践 19C 的 GI 升级。
前面提到过，Oracle 19C 替代 12C 将成为 Oracle 线条接下来这两年的主要工作。笔者所在客户现场的后续数据库集成安装都将以 19C 为标准版本。本文就以 19C 打最新的 GIRU(19.7.0.0.200414)步骤及遇到的问题做总结分享。
GIRU 实施步骤
补丁升级均采取滚动升级方式进行。
1、19 更新 OPatch 版本
打 GIRU(19.7.0.0.200414)所需要的 OPatch 版本为 12.2.0.1.19 及以上最新版本。建议使用 19C 版本进行补丁升级，所以我们这次使用的 OPatch 是 19C，具体命令如下：
更换GI HOME的opatch版本:su - gridcd /oracle/app/19.3.0/grid/cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./mv OPatch OPatch_20200622unzip p6880880_190000_Linux-x86-64.zipchown -R grid:oinstall OPatchchmod -R 775 OPatch/oracle/app/19.3.0/grid/OPatch/opatch version
更换DB HOME的opatch版本:su - oraclecd /oracle/app/oracle/product/19.3.0/dbcp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./mv OPatch OPatch_20200622unzip p6880880_190000_Linux-x86-64.zip/u01/app/oracle/product/12.2.0.1/dbhome_1/OPatch/opatch version
复制代码
2、目录备份
该备份将作为补丁升级出错，rollback 也报错时的最后救命稻草。备份 app 及 oraInventory 两目录即可。
ps -ef|grep LOCAL=NO|awk '{print $2}'|xargs kill -9srvctl stop instance -d racdb -n racdb1su - root/oracle/app/19.3.0/grid/bin/crsctl stop crs/oracle/app/19.3.0/grid/bin/crsctl stat res -ttar -cvf /oraclelog/pa/opatch_20200622/gi_home_`hostname`_20200622.tar /oracle/apptar -cvf /oraclelog/pa/opatch_20200622/oraInventory_`hostname`_20200622.tar /oracle/app/oraInventory
复制代码
备份目录为啥要停库停 CRS？部分看官们估计会有疑问。这个还得从很早之前一次 Oracle 11G GI PSU 升级说起，当时笔者碰到这样一种情况，在确认当时备份命令运行正常，备份出来的文件大小正常情况下，在不停 CRS 的情况下备份出来的文件竟然不可用…还好当时值得庆幸的是补丁回滚成功了。所以这次“惊魂动魄”之后这个备份都“唯经验论”了。
3、拉起 CRS 进行补丁冲突分析
启动crs,不起db/oracle/app/19.3.0/grid/bin/crsctl start crs/oracle/app/19.3.0/grid/bin/crsctl stat res -ttail -100f /oracle/app/grid/diag/crs/*/crs/trace/alert*.log补丁冲突分析su - gridopatch prereq CheckConflictAgainstOHWithDetail –phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869304opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30898856su - oracleopatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985su - rootcd /oraclelog/pa/opatch_20200622/30899722/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/pa/opatch_20200622/30899722 -analyze
复制代码
预计这里有的看官又有疑问了，为啥启动 CRS，不起 DB？升级过程 GI 会自动把 DB 及 CRS 停下来并进行目录升级，这样不是多此一举吗。
各位看官应该清楚，繁忙生产库的 DB 因为并发和繁忙程度是没这么容易停下来的，一般作为老鸟来说，为了最大限度的万无一失，都会手动 kill 会话及手动做 checkpoint，switch logfile 让系统在自己眼皮子底下顺利停下来。这样做一来让系统停机可控，二来避免因让系统自动去停 DB 可能导致的各种各样的问题（如导致打补丁需要很长的时间等）。
冲突分析部分截图：
4、实施补丁
su - rootcd /oraclelog/shsnc/opatch_20200622/30899722/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/shsnc/opatch_20200622/30899722
复制代码
5、 数据字典更新并检查
在所有节点补丁实施完成后，拉起实例，开始数据字典更新。
su - oraclecd $ORACLE_HOME/OPatch./datapatch -verbose--检查补丁./opatch lsinventorysqlplus / as sysdbaset line 300 pages 100col ACTION_TIME for a30col DESCRIPTION for a60select PATCH_ID, FLAGS,ACTION,STATUS,INSTALL_ID,ACTION_TIME,DESCRIPTION from DBA_REGISTRY_SQLPATCH order by ACTION_TIME;
复制代码
补丁升级成功截图：
问题汇总
1、补丁升级失败，报 oui-patch.xml 文件没有权限
报错截图如下：
从以上截图我们可以看到补丁在 DB HOME 已经成功应用，但是在 GI HOME 应用时失败，报/oracle/app/oraInventory/ContentsXML/oui-patch.xml 文件权限问题。我们查看文件权限发现问题所在，同组 grid 用户该文件无写权限。
补丁回滚失败后，把之前备份的目录 tar 回来发现数据库安装之后是没有这个文件的。由此我们可以知道 oui-patch.xml 是在 DB HOME 进行补丁升级时派生的。
再次进行补丁升级时，发现 oui-patch.xml 已生成。
紧急给 oui-patch.xml 赋予 664 权限（注：只要文件一旦生成，需立即赋权），补丁升级成功。
Warning 是告知实例未启动，需要手动启动并运行脚本进行数据字典更新，可忽略。
2、补丁升级成功之后，节点 1 CRS 报错如下
在节点 1 CRS alert 日志中我们发现节点 1 会去检查所有节点的这些文件。当发现文件不存在时就报该错。前往各节点查看这些文件，确认在所有节点都不存在。
核实部分截图：
这些 Jackson 开头的 JAR 包均是 Jackson 工具所属 JAR 包。从当前来看这个应该是 Oracle 为以后版本新功能准备的，但是当前目录又没有添加对应的 JAR 包，所以报错。通过核查集群及数据库均确认正常的情况下，该报错可忽略。
总结
以上两个报错在 MOS 均查不到详细信息，对于本来就是吃螃蟹的尝新过程，或多或少会遇到各种未知 BUG，这个过程我们遇山开路，逢水搭桥，依托自己的功力，相信自己，总会找到问题的原由及解决方案。
作者介绍：
魏斌，新炬网络资深数据库专家，长期服务于运营商、金融、制造业及政企客户。从传统商业 DB 到开源分布式，均有涉猎及独到见解。职业以来扎根客户一线，对于紧急故障处置及性能问题优化具有丰富经验，尤善于灾备、多中心建设及异构数据迁移。
原文链接：
Oracle 19c GI升级，遭遇未知BUG也不慌
评论