Oracle 19c GI升级,遭遇未知BUG也不慌-数据与编程-热点资讯-野望文存-科技 
    欢迎来到野望文存-科技!
当前位置:野望文存-科技 > 热点资讯 > 数据与编程 >  Oracle 19c GI升级,遭遇未知BUG也不慌

Oracle 19c GI升级,遭遇未知BUG也不慌

发表时间:2020-08-07 07:15:00  来源:野望文存  浏览:次   【】【】【


作者介绍

魏斌,新炬网络资深数据库专家,长期服务于运营商、金融、制造业及政企客户。从传统商业DB到开源分布式,均有涉猎及独到见解。职业以来扎根客户一线,对于紧急故障处置及性能问题优化具有丰富经验,尤善于灾备、多中心建设及异构数据迁移。


大家好,今天咱来实践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 - 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


2、目录备份


该备份将作为补丁升级出错,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?部分看官们估计会有疑问。这个还得从很早之前一次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 -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可能导致的各种各样的问题(如导致打补丁需要很长的时间等)。


冲突分析部分截图:





4、实施补丁



su - root

cd /oraclelog/shsnc/opatch_20200622/30899722

/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/shsnc/opatch_20200622/30899722


5、 数据字典更新并检查


在所有节点补丁实施完成后,拉起实例,开始数据字典更新。



su - oracle

cd $ORACLE_HOME/OPatch

./datapatch -verbose

--检查补丁

./opatch lsinventory

sqlplus / as sysdba

set line 300 pages 100

col ACTION_TIME for a30

col DESCRIPTION for a60

select 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,这个过程我们遇山开路,逢水搭桥,依托自己的功力,相信自己,总会找到问题的原由及解决方案。


作者丨魏斌
来源丨IT那活儿(ID:justdoit2019syy)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn



云时代下数据库将如何革新与创变?金融行业核心数据库迁移与建设如何安全平稳展开?开源技术如何在实际业务场景中发挥实力?10月30日,DAMS中国数据智能管理峰会将在上海举办,专设【数据库分场】,部分议题如下:


  • 《All in Cloud时代,下一代云原生数据库技术与趋势(拟)》阿里巴巴 集团副总裁 李飞飞(飞刀)

  • 《从自研演进看分布式数据库》国银联 云计算中心团队主管 周家晶

  • 《开源数据库MySQL在民生银行的应用实践》民生银行 项目经理 徐春阳

  • 《TDSQL在金融行业数据库上云实战》腾讯云 高级经理 陈琢


立即扫码享受早鸟价,在数据库变迁中站稳脚跟!


责任编辑:蔡学森