数据库管理第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到底做了些啥：

1. 补丁检查（这一步也建议预先做了）
2. 关闭CRS（包括DB）
3. DB home应用补丁
4. GI home应用补丁
5. 启动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和升级流程非常了解。
老规矩，知道写了些啥。