一次ASM磁盘组扩容引发的“踩坑”丨本际云推荐

一次ASM磁盘组扩容引发的“踩坑”

一.背景

因生产需求，要对一套即将上线的19C版本3节点RAC数据库库ASM磁盘组进行扩容操作，原本以为是个很简单的操作，岂料结果踩了个坑，不过好在顺利解决，还排除了一个隐患。报错信息如下：

一次ASM磁盘组扩容引发的“踩坑”

根据报错信息查看当前集群环境状态：查询结果与报错信息一致，显示该集群处理滚动升级状态，然而当前并无补丁升级操作。查看MOS文档，怀疑kfodop=patches及kfodop=PATCHLVL信息可能不一致：

节点1：

节点2：

节点3：

并未命中，只能从其他方面进一步排查。

后来想到这套库前一段时间进行了PSU升级，其中在进行第一个节点升级的过程中因为心跳网络未加入到白名单出现异常，故而怀疑本次报错是否和此有关联。检查各个节点已配置补丁程序级别：

节点1：

节点2：

节点3：

果然，节点1已配置补丁程序级别与其他两个节点不一致。匹配MOS文档(DocID1639285.1)对节点1补丁级别进行修正，具体方法如下：

[root@GG1install]#/u01/app/19.0.0/grid/crs/install/rootcrs.sh-prepatch

Usingconfigurationparameterfile:/u01/app/19.0.0/grid/crs/install/crsconfig_params

Thelogofcurrentsessioncanbefoundat: /u01/app/grid/crsdata/bh14-bhx-gg1/crsconfig/crs_prepatch_apply_inplace_gg1_2021-03-25_04-32-51PM.log

2021/03/2516:32:52CLSRSC-671:Pre-patchstepsforpatchingGIhomesuccessfullycompleted.

[root@GG1install]#/u01/app/19.0.0/grid/crs/install/rootcrs.sh-postpatch

Usingconfigurationparameterfile:/u01/app/19.0.0/grid/crs/install/crsconfig_params

Thelogofcurrentsessioncanbefoundat: /u01/app/grid/crsdata/bh14-bhx-gg1/crsconfig/crs_postpatch_apply_inplace_gg1_2021-03-25_04-33-11PM.log

OracleClusterwareactiveversionontheclusteris[19.0.0.0.0].Theclusterupgradestateis[NORMAL].Theclusteractivepatchlevelis[869426834].

2021/03/2516:35:16CLSRSC-4015:PerforminginstallorupgradeactionforOracleTraceFileAnalyzer(TFA)Collector.

2021/03/2516:35:16CLSRSC-4003:SuccessfullypatchedOracleTraceFileAnalyzer(TFA)Collector.

2021/03/2516:35:18CLSRSC-672:Post-patchstepsforpatchingGIhomesuccessfullycompleted.

再次检查节点1已配置补丁级别，发现已修正完成。ASM磁盘扩容操作顺利完成：

本次处理过程，主要还是在于上次补丁升级遗漏的问题：补丁升级完成后，检查补丁号，升级记录都正常，然而节点1的已配置补丁程序级别却存在异常，与其他两个补丁升级顺利完成的节点不同；看来以后补丁升级后要更细致的检查确认，尤其要验证补丁级别。

原创文章，作者：小编小本本，如若转载，请注明出处：https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/6078.html