本文主要是介绍数据库管理-第162期 我敢在升级过程中ctrl+c，你敢么（20240320），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
数据库管理162期 2024-03-20
- 数据库管理-第162期 我敢在升级过程中ctrl+c，你敢么（20240320）
- 1 背景
- 2 问题1
- 3 问题2
- 4 解决
- 总结
数据库管理-第162期 我敢在升级过程中ctrl+c，你敢么（20240320）
作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
国内某科技公司 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家，OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭。
春分到来，因为昨天凌晨割接了，昨天休息了一天，今天就给昨天割接过程中的小插曲总结分享一下。
1 背景
为了彻底解决在《数据库管理-第155期 记一次发生在备库上的故障处理（20240226）》中那个会导致实例异常重启的BUG，给数据库打19.22补丁（关于RAC上的升级操作，请看第七十六期）。这中间出现了俩问题：1.备库因为BUG的问题，在第一个节点opatchauto时另外3个节点数据库实例都挂了；2.主库在应用SQL Patch的时候卡了一小时。下面就跟随总监一起看看我是咋解决的。
2 问题1
其实这个问题挺好解决的，看了下挂掉实例的日志，确认是BUG引起的，那么还是按照之前的操作来，把除已经打好补丁的节点以外的节点都先干掉：
sudo /u01/app/19.0.0/grid/bin/crsctl stop crs -f
然后再启动下一个节点，并应用补丁：
sudo /u01/app/19.0.0/grid/bin/crsctl start crs
sudo /u01/app/19.0.0/grid/OPatch/opatchauto apply /path/to/patch/
在第二个节点补丁升级操作完成后确认节点一实例未出现异常，因此继续完成剩余节点补丁升级，未再出现问题。
3 问题2
首先重新梳理一下opatchauto到底做了些啥：
- 补丁检查（这一步也建议预先做了）
- 关闭CRS（包括DB）
- DB home应用补丁
- GI home应用补丁
- 启动CRS（包括DB）
这是常规的基本流程，在opatchauto判断到最后一个节点时，将增加sqlpatch的操作，等效于下面的操作：
$ORACLE_HOME/OPatch/datapatch -verbose
而这部分在opatchauto过程中是看不到日志位置的，日志位置在：
/u01/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_xxxxx_2024_03_19_xx_xx_xx/
在该目录下，sqlpatch_catcon_x.log则记录了对应容器的sqlpatch的操作日志，经过对每个日志文件检查，发现是有个PDB执行卡住了。在这个目录下还有一个文件，记录了干掉每个容器的操作会话：
sqlpatch_catcon__catcon_kill_sess_xxxxx_ALL.sql
在sqlplus里面执行即可终止sqlpatch操作：
start sqlpatch_catcon__catcon_kill_sess_xxxxx_ALL.sql
然后在opatchauto的终端果断按下了:
ctrl+c
结束了opatchauto。
4 解决
后面还有OJVM，因此用手工采用rolling的方式把OJVM补丁先打了，重新启动实例后确实发现之前卡住的PDB处在restricted状态，因此手工重新跑了sqlpatch：
$ORACLE_HOME/OPatch/datapatch -verbose
这次没有出现问题，看了下EMCC，应该是打第一次sqlpatch有些SQL影响了打补丁操作，再次重启后没有这些SQL了。
总结
本次解决了在升级过程中的两个问题，需要对RAC和升级流程非常了解。
老规矩，知道写了些啥。
这篇关于数据库管理-第162期 我敢在升级过程中ctrl+c，你敢么（20240320）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
