背景：集群宕机以后，重启报错，DATADG1磁盘组无法启动

1.手动挂起DATADG1磁盘组报错

1	`alter` `diskgroup datadg1 mount;`

SQ-> alter diskgroup DATADGI mount; alter diskgroup DATÅDGI mount ERROR at line 1: ORA-15032: not all alterations perfomed ORA-15017: diskgroup "DATADGI" cannot be mounted CPA-15063: ASM discovered an insufficient nunber of disks for diskgroup "DATADGI"

后台ASM报错

根据报错 found 0 disks 怀疑是磁盘组里的磁盘有问题，没有启动

2.查询磁盘状态

1	`select` `name` `,path,STATE,MODE_STATUS` `from` `v$asm_disk;`

OCPDGI 0000 FRADGI 0000 PATH /dev/ rhdiskpower4 /dev/ rhdiskpower2 /dev/ rhdiskpower3 /dev/ rhdiskpowero /dev/ rhdiskpowerl STATE NOR4AL NOR4ßL NOR•IAL NOR•IAL NOR•IAL t•it.i.æ 7 ON-IFE- otLIE-

发现磁盘都在，但是磁盘组没法跟磁盘对应起来

3.硬件工程师检查硬盘、以及存储网关都正常，磁盘权限也正常

4.怀疑是磁盘头损坏了，导致磁盘组跟磁盘无法对应

1	`select` `group_Number,disk_number,mount_status ,header_status` `from` `v$asm_disk;`

sot> / PATH / dev/ rhdi s kpower4 / dev/ rhdi s kpower2 3 / dev/ rhdi s kpower3 / dev/ rhdi s kpowerl / dev/ rhdi s kpowero MOUNT S HEADER STATU MODE sr STATE 0 CLOSED CLO ED CLO ED CACHED CACHED MEMBER CANDIDATE MEMBER MEMBER ONI, INE NI,INE NLINE ONLINE ONLINE NORMAL NORMAL NORMAL NORMAL NORMAL TOTAL MB 1048576 10240 FREE MB LABEL 991687 9844

发现2，3磁盘头状态为CANDIDATE

5.使用kfed查看磁盘头

1	`kfed` `read` `/dev/rhdiskpower2`

kfbh.type显示异常正常情况下应该是KFBTYP_DISKHEAD

6.修复2,3磁盘头

从版本10.2.0.5开始ASM 会对disk header做一个额外的备份。即第二AU 的倒数第二个block中备份了一份KFBTYP_DISKHEAD。这个ASM Disk header的作用是当真的KFBTYP_DISKHEAD被意外覆盖或损坏时可以使用Oracle 工具 KFED使用repair选项来修复Disk header

kfed repair //dev/rhdiskpower2

此时检查磁盘头状态正常，显示为KFBTYP_DISKHEAD

7.一节点的数据库反复重启

修复磁盘头以后，磁盘能够正常挂起，并且数据库能够拉起

但是数据库在运行一段时间后，出现宕机

数据库日志显示 IO错误

由于操作系统为AIX，排查两个节点的磁盘参数

1	`lsattr -El hdisk20 \| grep reserve`

发现二节点并没有设置no_reserve

这个参数的作用：这个参数其实是表示操作系统是否持有存储卷的共享锁方式

设置

1	`chdev -l hdisk21 -a reserve_policy=no_reserve`

设置完成后，一节点能够正常运行

8.二节点gpnpd服务无法启动

根据gipcd 日志信息

匹配到官方文档Doc ID 2034669.1

删除以上三个目录的缓存，重启rac，二节点启动成功

ITPub博客

磁盘故障处理案例

最新文章