ORA-15038: disk '/dev/mapper/mpath' mismatch on 'Time Stamp' 解决

由于磁盘组新加磁盘是使用过的磁盘，还有其他磁盘组成员未进行dd操作，恰巧原来磁盘组名称和现有磁盘组名称都叫dgdata，导致报错—往往由于我们忽视了最初的一个点，导致了耗费了巨大的代价，最后都会默默自嘲，原来是这样！！！

早上一个同学让帮忙看看数据库集群重启报错的原因。


启动集群，直接报了如下的错：

但是日志中显示dg都mount了啊，为何还是报错呢？

然后尝试手动启动asm试试看

结果依然是同样的错误。

然后我们怀疑是多路径绑定的问题。
对比了两节点的多路径的conf文件还有/etc/udev/rules.d/12-dm-permissions.rules文件里边都没有问题，但是发现盘符不一致


重启以后依然还是报错，盘符还是有问题。
最后问存储工程师说，是用wwid绑定的磁盘组，证明这个 也是没有问题的，排除这个可能性。
然后无奈了！！！
网上找了maclean的一些文章，说要对比一下两端磁盘头信息是否一直。发现也是一致的，类似如下的情况


然后看了一下报错的信息：
Error code: ORA-15038
Description: disk ‘string’ mismatch on ‘string’ with target disk group [string] [string]
Cause: An attempt was made to mount into a disk group a disk whose recorded allocation unit size, metadata block size, physical sector size, or creation time stamp was inconsistent with the other disk group members.
Action: Check if the system configuration has changed. Verify disk discovery string.
说是磁盘组的磁盘头信息时间戳和其他磁盘组时间戳不一致导致的原因。
然后使用kfed查看两端磁盘头信息也是一致的啊：类似如下：

然后没办法了，然后就和之前的人员对接情况，才发现，那些新加磁盘是使用过的磁盘，并且老磁盘组的名称和新磁盘组名称一致都是dgdata，虽然新加进磁盘已经dd添加进去了，但是还有其他老磁盘组的磁盘成员未进行dd操作，导致重启之后，集群启动检测磁盘组发现有两个名为dgdata的磁盘组发生冲突报错！！！最后将老的磁盘组的剩余磁盘成员dd格式完成以后，启动asm服务成功，最终启动rac集群成功！！！