12c补丁升级_集成安装之oracle19C GI升级遇坑分享

最新推荐文章于 2024-03-23 14:05:20 发布

九老师

最新推荐文章于 2024-03-23 14:05:20 发布

阅读量595

点赞数

文章标签： 12c补丁升级

本文链接：https://blog.csdn.net/weixin_35949264/article/details/112572553

版权

亲爱滴伙伴们！本萎专家又来了，今天咱来实践19C的GI升级。

前面提到过，Oracle19C替代12C将成为oracle线条接下来这两年的主要工作。本萎大湿所在客户现场后续数据库集成安装都将以19C为标准版本。本篇就19C打最新的GIRU(19.7.0.0.200414)步骤及遇到的问题做总结分享。

● GIRU实施步骤●

补丁升级均采取滚动升级方式进行

0119更新opatch版本

打GIRU(19.7.0.0.200414)所需要的opatch版本为12.2.0.1.19及以上最新版本。建议使用19C版本进行补丁升级，所以我们这次使用的opatch是19C，具体命令如下：

更换GI HOME的opatch版本:

su - grid

cd /oracle/app/19.3.0/grid/

cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./

mv OPatch OPatch_20200622

unzip p6880880_190000_Linux-x86-64.zip

chown -R grid:oinstall OPatch

chmod -R 775 OPatch

/oracle/app/19.3.0/grid/OPatch/opatch version

更换DB HOME的opatch版本:

su - oracle

cd /oracle/app/oracle/product/19.3.0/db

cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./

mv OPatch OPatch_20200622

unzip p6880880_190000_Linux-x86-64.zip

/u01/app/oracle/product/12.2.0.1/dbhome_1/OPatch/opatch version

02目录备份

该备份将作为补丁升级出错，rollback也报错时的最后救命稻草。备份app及oraInventory两目录即可。

ps -ef|grep LOCAL=NO|awk '{print $2}'|xargs kill -9

srvctl stop instance -d racdb -n racdb1

su - root

/oracle/app/19.3.0/grid/bin/crsctl stop crs

/oracle/app/19.3.0/grid/bin/crsctl stat res -t

tar -cvf /oraclelog/pa/opatch_20200622/gi_home_`hostname`_20200622.tar /oracle/app

tar -cvf /oraclelog/pa/opatch_20200622/oraInventory_`hostname`_20200622.tar /oracle/app/oraInventory

备份目录为啥要停库停CRS？部分看官们估计会有疑问。这个还得从很早之前一次Oracle11G GI PSU升级说起，当时本萎大湿碰到这样一种情况，在确认当时备份命令运行正常，备份出来的文件大小正常情况下，在不停CRS的情况下备份出来的文件竟然不可用......还好当时值得庆幸的是补丁回滚成功了。。所以这次“惊魂动魄”之后这个备份都“唯经验论”了。

03拉起CRS进行补丁冲突分析

启动crs,不起db

/oracle/app/19.3.0/grid/bin/crsctl start crs

/oracle/app/19.3.0/grid/bin/crsctl stat res -t

tail -100f /oracle/app/grid/diag/crs/*/crs/trace/alert*.log

补丁冲突分析

su - grid

opatch prereq CheckConflictAgainstOHWithDetail –phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869304

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30898856

su - oracle

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985

su - root

cd /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可能导致的各种各样的问题(如导致打补丁需要很长的时间等)。

冲突分析部分截图：