oracle:记一次磁盘头故障处理

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

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

sql 复制代码
alter diskgroup datadg1 mount

后台ASM报错

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

2.查询磁盘状态

sql 复制代码
select name,path,STATE,MODE_STATUS from v$asm_disk;

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

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

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

sql 复制代码
select group_Number,disk_number,mount_status ,header_status from v$asm_disk;

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

5.使用kfed查看磁盘头

sql 复制代码
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,排查两个节点的磁盘参数

sql 复制代码
lsattr -El hdisk20 | grep reserve

发现二节点并没有设置no_reserve

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

设置

sql 复制代码
chdev -l hdisk21 -a reserve_policy=no_reserve

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

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

根据gipcd 日志信息

匹配到官方文档Doc ID 2034669.1

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

相关推荐
这个DBA有点耶1 小时前
NULL不是空——数据库里最反直觉的设计,90%新人踩过的坑
数据库·mysql·代码规范
这个DBA有点耶3 小时前
AI写的SQL跑崩了生产库,这锅谁背?
数据库·人工智能·程序员
镜舟科技4 小时前
Databricks 再提 LTAP,AI 时代的数据底座为何重回大一统叙事?
数据库·架构·agent
Databend4 小时前
从湖仓升级为 Agent 时代的数据控制面,Snowflake 和 Databricks 有哪些布局
大数据·数据库·agent
ClouGence8 小时前
SQL Server CDC 能放到 Always On 备库读吗?一文讲透原理与实践
数据库·sql server
先吃饱再说1 天前
存储的进化:从 MySQL 到浏览器缓存,数据到底住在哪?
数据库
Nturmoils1 天前
字段太多看不全,ksql 的展开模式和输出控制怎么用
数据库·后端
Databend1 天前
Agent 轨迹分析与归因的数据工程实践
大数据·数据库·agent
这个DBA有点耶1 天前
SQL改写进阶:标量子查询的“隐形代价”与消除实战
数据库·mysql·架构
smallyoung1 天前
数据库乐观锁深度解析:MySQL、PostgreSQL 实战 + Spring Boot 集成指南
数据库·mysql·postgresql