oracle创建磁盘组报错ORA15137

oracle 创建磁盘组报错 ORA-15137

• 集群处于ROLLING PATCH模式
• 背景
• 收集信息
• mos
• 解决
• 问题原因
• 手动安装补丁，没有执行rootcrs.sh的脚本
• 问题现象
• 问题原因
• 问题解决

asm扩容本来是件很简单的事，当asm磁盘准备好之后，直接一条命令就会添加上。但是也会有异常情况，最近就碰到19c在扩容的时候，报错的故障，供大家参考。

背景

某ERP数据库采用Oracle 19c RAC集群，部署架构为传统架构即两台计算节点外挂集中存储。ASM的DATA磁盘组空闲较小需扩容，执行对DATA磁盘组的扩容操作，但报错失败



报错ORA-15137.这个报错还没见过。我们通过完整的分析过程来展现分析思路。

收集信息

1、查看asm磁盘组现有状态

通过命令查询，ASM的DATA磁盘组用于存放数据文件；ARCH磁盘组用于存放归档文件。

其中DATA磁盘组总量2TB，目前还空闲可用约300GB；ARCH磁盘组总量1TB，目前空闲可用约700GB。

2、查看磁盘（权限和属组）

1.通过lsblk命令查询，sdf,sdg,sdh,sdi均为1TB磁盘；

2.通过scsi_id命令查询磁盘ID；

3.通过查看99-oracle-asmdevices.rules文件，在1月14日进行了修改，将3604fe8d100d5d230b888210a00000038磁盘绑定了别名asm-data03。

4.在/dev目录下查看绑定状态正确无误。

补充：

验证属组权限的，还有一个更快捷的方法，kfod，因为当我们创建磁盘组的时候，oracle就是调用kfod命令来发现磁盘的，如果能够被kfod识别，那这块盘就能够被oracle正确识别：





常用验证命令：

3、查看asm alert日志，是否还有更多信息：



和前台界面报错一样，ORA-15137,再没有更多信息。

现在就是新加的这块盘没有问题，不管是os，还是oracle，都能够正常识别这块盘。按理说是可以正常扩容成功的，但是asm实例就是添加报错。

mos

现在只有查询官方文档了。看有没有蛛丝马迹。

通过报错关键词查询（ORA-15137: The ASM cluster is in rolling patch state.）

匹配文档： [OCI] Scale-up Failed in DBCS With ORA-15032: not all alterations performed, ORA-15137: The ASM cluster is in rolling patch state (Doc ID 2681040.1)

为两台计算节点补丁不一致，list of patches在计算节点1缺少一个， patch level值不一致。

1节点：

2节点：

上述的state is [ROLLING PATCH]，一般显示为state is [NORMAL]。此处已经异常。

可以看出两点：1、集群处于ROLLING PATCH模式；

2、对比发现，crs softwarepatch补丁信息不一致，而且kfod工具的补丁，2节点比1节点多一个补丁。

看起来是由于2个节点的补丁不一致，导致集群处于ROLLING PATCH模式导致的。那为什么会有补丁信息不一样的情况 哪？因为我们打补丁的时候，是通过opatchauto自动打的，而且是2个节点一起打的，经询问，打补丁的过程没有报错。这个就比较奇怪了。打算提个sr咨询下原厂，因为未来还要大批量的打补丁，这将是个隐患。

补充：这种查看补丁的方式还是第一次用，以前常用的都是opatch lspatches和opatch lsinventory来查看节点的补丁信息，如下：







对比发现：两节点安装的RU是一致的。所以在此处，此方法查看补丁的方法是行不通的。

小结：通过命令和日志查询，发现在1月14日早9时，进行了udev绑定状态正常，进行了DATA磁盘组添加磁盘，报错失败。经过搜索查询，疑似为两台计算节点补丁不一致造成。目前数据库使用状态正常，管控应用使用状态正常。

解决

以下所有的操作都是在多余的补丁的那个节点操作的，即2节点操作

1、停止2节点数据库：shutdown immediate

2、 ./rootcrs.sh -prepatch

3、 ./patchgen commit -rb 29757256(29757256是节点二多余的那个补丁)

4、./rootcrs.sh -postpatch

执行完第三步会报错，按照MOS文档 2348013.1 处理



5、 ./rootcrs.sh -prepatch

6、./rootcrs.sh -postpatch

7、asmcmd进去，showclusterstate,在检查patch状态，从rolling变为normal

至此，添加asm磁盘正常。

问题原因

本次故障就是因为安装补丁的时候，由于未知原因，导致kfod这个工具的补丁不一致，集群处于ROLLING PATCH模式，识别asm磁盘都没有问题，但是会导致asm扩容失败。

今天在测试环境，创建磁盘组的时候，报错了，虽然不知道问题是怎样产生的，但是最后解决了，特此记录以下。

问题现象

create diskgroup xxxxx;

ORA-15018: Diskgroup can not be created

ORA-15137: cluster in rolling patch

问题原因

猜测是因为打19.4.2的补丁的时候用的不是opatchauto打的，打的时候没有跑rootcrs.sh的脚本导致的

问题解决

如果下面命令查询2个节点命令不一致的话可以用下面的方法结决，可惜我的2个节点一致这个方法不行

crsctl query crs softwarepatch

crsctl stop rollingpatch

2个节点分别跑rootcrs.sh的脚本，问题得到解决

/crs/install/rootcrs.sh -prepatch

/rdbms/install/rootadd_rdbms.sh

If this is an Oracle Restart Home, as the root user execute:

/crs/install/rootcrs.sh -postpatch

参考:

[OCI] Scale-up Failed in DBCS With ORA-15032: not all alterations performed, ORA-15137: The ASM cluster is in rolling patch state (Doc ID 2681040.1)

Patching 12.2.0.1 Grid Infrastructure gives error CRS-6706: Oracle Clusterware Release Patch Level (‘748994161’) Does Not Match Software Patch Level (Doc ID 2348013.1)