由于磁盘组新加磁盘是使用过的磁盘,还有其他磁盘组成员未进行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集群成功!!!



©著作权归作者所有:来自51CTO博客作者小麦苗DB宝的原创作品,如需转载,请注明出处,否则将追究法律责任

更多相关文章

  1. 【ASM】ASMCMD 磁盘元数据的备份与恢复实践
  2. 在k8s集群部署SonarQube
  3. 使用kubeadm搭建高可用k8s v1.16.3集群
  4. 【ASM】Oracle ASM + 11gR2 + RHEL6.5 安装
  5. 【DB笔试面试739】在Oracle中,如何获取集群的名称(Cluster name)?
  6. 【DB笔试面试719】在Oracle中,什么是OCR、OLR和VF?
  7. 使用kubeadm部署Kubernetes v1.13.3
  8. 一键获取linux内存、cpu、磁盘IO等信息脚本编写,及其原理详解
  9. 与亲生的Redis Cluster,来一次亲密接触

随机推荐

  1. Android增大button响应区域
  2. Android Package的使用情况统计
  3. Android(安卓)屏幕旋转重新调用onCreate
  4. Android 监控程序安装和删除的实现
  5. Android程序开发基础之——页面布局
  6. Android之单元测试
  7. Android(安卓)Memory Management, OutOfM
  8. 在Android(安卓)Studio 2.2上集成OpenCV
  9. github项目解析(五)-->android日志框架
  10. Android(安卓)Retrofit 2.0(一)初次见面请