红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

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

  • 2020-08-19
  • 本文字数:2717 字

    阅读完需:约 9 分钟

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

本文由 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也不慌


2020-08-19 10:111368

评论

发布
暂无评论
发现更多内容

MobPush自定义智能标签,赋能精细化运营

MobTech袤博科技

智能推送

企业几种快速传输大文件的使用方法,你GET到了吗

镭速

大文件传输 传输大文件

软件项目验收计划书

金陵老街

After Effects 2024 for Mac(ae视频特效制作工具) v24.0.2永久激活版

mac

windows 苹果mac After Effects 2024 AE2024 视频特效制作软件

企业级API资产如何管理

RestCloud

API 资产管理 API 接口

如何使用商品详情API接口来获取想要的商品数据?

Noah

DAPP合约代币质押算力挖矿系统开发

l8l259l3365

如何使用商品详情API接口获取商品数据:一篇详尽的论述

Noah

Flink JobManager内存管理机制介绍与调优总结

腾讯云大数据

flink、

HarmonyOS数据管理与应用数据持久化(二)

HarmonyOS开发者

iZotope RX 10 for mac(音频修复和增强工具) 10.4.2完整激活版

mac

苹果mac Windows软件 iZotope RX 10 音频修复软件

git原理与基本应用

丛风

git

Techwalk攻略 | 来北京与OpenHarmony技术大会一起技术漫游!

OpenHarmony开发者

混合云场景下基于 Fluid 的焱融高效存储方案

焱融科技

推送没人看?MobPush助力APP运营提质增效

MobTech袤博科技

MobPush后台配置教程

MobTech袤博科技

智能推送

以技术创新,让美好发生!第二届华为云杯“少年开发者”人工智能大赛总决赛成功落幕

彭飞

Lightsail CDN 现已对 Lightsail Container Services 作为来源进行支持

亚马逊云科技 (Amazon Web Services)

CDN Amazon Lightsail Amazon CloudFront

Stable Diffusion 的提示词使用技巧

3D建模设计

Stable Diffusion 自动纹理

MobPush智能推送:数智化运营释放APP用户生命周期价值

MobTech袤博科技

.NET CORE 之gRpc使用

gogo

喜讯!云起无垠获评GEEKCON 2023"前沿突破奖"

云起无垠

MobPush智能推送工具,助力实现用户全生命周期管理

MobTech袤博科技

智能推送

dapp质押挖矿、理财分红系统定制开发

西安链酷科技

区块链 dapp 去中心化 交易所 质押挖矿

dapp开发需要多少钱、dapp软件开发公司

西安链酷科技

软件开发 dapp 去中心化 交易所

跨平台.NET IDE集成开发 JetBrains Rider注册码激活版

mac大玩家j

代码编辑器 Mac软件

Util应用框架介绍

何镇汐

C# 后端 软件开发 开源框架’

生信领域|焱融存储为极智基因打造高性能生物医学平台

焱融科技

利用稳定扩散快速修复图像

3D建模设计

人工智能「 Stable Diffustion 图像修复

云原生微服务的下一站:Proxyless Service Mesh

华为云开发者联盟

微服务 云原生 华为云 华为云开发者联盟

一图看懂华为云CodeArts Link六大特性,带你体验一站式跨平台数据互联

华为云PaaS服务小智

云计算 软件开发 华为云

Oracle 19c GI升级,遭遇未知BUG也不慌_数据库_dbaplus社群_InfoQ精选文章