根据以上的进行串联，模拟问题处理步骤

Part1编译Kfed

默认是 grid 用户，但是oracle用户也可以
可以是在grid执行就报错

su - grid
cd $ORACLE_HOME/rdbms/lib
make -f ins* ikfed

这个我在grid用户做过，但是报错异常，说是权限不对，Oracle用户却可以

[grid@ ]$ make -f ins* ikfed

Linking KFED utility (kfed)
rm -f /u01/app/11.2.0/grid/rdbms/lib/kfed
gcc -o /u01/app/11.2.0/grid/rdbms/lib/kfed -m64 -z noexecstack -L/u01/app/11.2.0/grid/rdbms/lib/ -L/u01/app/11.2.0/grid/lib/ -L/u01/app/11.2.0/grid/lib/stubs/  /u01/app/11.2.0/grid/lib/s0main.o /u01/app/11.2.0/grid/rdbms/lib/sskfeded.o /u01/app/11.2.0/grid/rdbms/lib/skfedpt.o -ldbtools11 -lcommon11 -lcell11 -lskgxp11 -lhasgen11 -lskgxn2 -lnnz11 -lxml11 -locr11 -locrb11 -locrutl11 -lhasgen11 -lskgxn2 -lnnz11 -lxml11  -lasmclnt11 -lclntsh  `cat /u01/app/11.2.0/grid/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /u01/app/11.2.0/grid/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnnz11 -lzt11 -lztkg11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lmm -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 `cat /u01/app/11.2.0/grid/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /u01/app/11.2.0/grid/lib/ldflags`    -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11   -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11 -lclient11 -lnnetd11  -lvsn11 -lcommon11 -lgeneric11 -lsnls11 -lnls11  -lcore11 -lsnls11 -lnls11 -lcore11 -lsnls11 -lnls11 -lxml11 -lcore11 -lunls11 -lsnls11 -lnls11 -lcore11 -lnls11   `cat /u01/app/11.2.0/grid/lib/sysliblist` -Wl,-rpath,/u01/app/11.2.0/grid/lib -lm    `cat /u01/app/11.2.0/grid/lib/sysliblist` -ldl -lm   -L/u01/app/11.2.0/grid/lib
test ! -f /u01/app/11.2.0/grid/bin/kfed || (\
   mv -f /u01/app/11.2.0/grid/bin/kfed /u01/app/11.2.0/grid/bin/kfedO &&\
   chmod 600 /u01/app/11.2.0/grid/bin/kfedO )
mv: 无法将"/u01/app/11.2.0/grid/bin/kfed" 移动至"/u01/app/11.2.0/grid/bin/kfedO": 权限不够
make: [ikfed] 错误 1 (忽略)
mv /u01/app/11.2.0/grid/rdbms/lib/kfed /u01/app/11.2.0/grid/bin/kfed
mv：是否覆盖"/u01/app/11.2.0/grid/bin/kfed"，而不理会权限模式0751 (rwxr-x--x)？ 
chmod 751 /u01/app/11.2.0/grid/bin/kfed
chmod: 更改"/u01/app/11.2.0/grid/bin/kfed" 的权限: 不允许的操作
make: [ikfed] 错误 1 (忽略)

Part2磁盘掉落无法识别

数据库有许多磁盘，因为业务原因导致磁盘使用和划分非常混乱，有的已经使用，有的却挂载保证下次使用，如果不是自己搭建或者过往时间较久，非常容易遗忘，虽然可以通过ASM后台alter日志通过创建语句比对，但是太过于麻烦，用 kfed read就很好用

#使用格式
kfed read [aun=ii aus=jj blkn=kk dev=]asm_disk_name

#默认格式
kfed read aun=0 aus=1048576 blkn=0 dev=asm_disk_name

#实战
#查询磁盘对应信息
kfed read dev=/dev/asm_arch_1 | grep name
代表磁盘的名称
kfdhdb.dskname:               ARCH_0000 ; 0x028: length=9
kfdhdb.grpname:                    ARCH ; 0x048: length=4
kfdhdb.fgname:                ARCH_0000 ; 0x068: length=9

#查询磁盘头状态是否正常（KFBTYP_INVALID代表状态异常）
kfed read dev=/dev/asm_arch_1 | grep type
块类型-磁盘头
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD


#磁盘组的编号（这个很有用）
kfed read dev=/dev/asm_arch_1 | grep dsknum
kfdhdb.dsknum:                        0 ; 0x024: 0x0000

#磁盘组的冗余级别
kfed read dev=/dev/asm_arch_1 | grep grptyp
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL

#查看ASM数据库大小
ASM磁盘组的块大小是4KB，但是最小的分配单元AU默认是1M
[grid@ :/ ]$ kfed read /dev/asm_arch_1 | grep blksize
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
4096字节 = 4KB

##对应报错
配对报错信息是 ORA-15196，能在ASM或者DB 的ALter日志中找到，需要找对实例节点

通过以上几个可以快速比对不熟悉的集群ASM磁盘组信息

Part3清理异常磁盘，重新挂载（适用于多次搭建集群）

#判断AU大小
kfed read dev=/dev/asm_arch_1  | grep ausize
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000

#或者登录数据库查询
sqlplus / as sysasm
SELECT dg.name "DG_NAME",
       d.name "DISK_NAME",
       dg.allocation_unit_size / 1048576 "AU_SIZE(MB)"
  FROM v$asm_disk d, v$asm_diskgroup dg
 WHERE d.group_number = dg.group_number;

#通过find查询AU信息的显示调试是否正确
（比如说默认块是4k，一个AU默认是1M，所以 AU * 1024（从M到KB） / 4 = 256 条，但是从0开始计算，所以是0-255）
kfed find dev=/dev/asm_ocr_1
出现任何非默认的信息都是异常的，很有可能出现数据问题。

##清理磁盘（其实count=1就行， count=1也是有点小心和多余了）
dd if=/dev/zero of=/dev/your_disk bs=1M count=4

块0是磁盘头

块1是 Free space table 空闲空间记录

块2-块255是磁盘的Allocation Table 分配表的记录

只有确定了需要清理磁盘的大小才能精准清理磁盘，否则以前出现过使用未处理的磁盘挂载到数据库集群里，结果导致数据出现异常出现数据丢失的情况发生。 而我以前杯弓蛇影，所以无论多大，都把整个磁盘进行清理，实在是没有必要。

Part4判断磁盘是否异常

用find找目录是否有问题
kfed find dev=/dev/asm_arch_1
报错信息是出现任何非默认信息就是异常

用read看内容是否异常
kfed read dev=/dev/asm_arch_1 | grep type
状态是KFBTYP_INVALID就是一场 

#修复ASM元数据库
[grid@ ]$ kfed read aun=0 blkn=2 dev=/dev/asm_arch_1 > /tmp/aun0_blkn2_asm_arch1.kfed

[grid@ :]$ kfed write aun=0 blkn=2 dev=/dev/asm_arch_1 text=/tmp/aun0_blkn2_asm_arch1.kfed chksum=yes

其实这个没太理解，找机会模拟一下

Part5对应的相关报错信息

KFBTYP_INVALID这个状态异常，配对报错信息是 ORA-15196，能在ASM或者DB 的ALter日志中找到，需要找对实例节点

ASM实例启动失败时的错误信息：
ORA-15196: invalid ASM block header
ORA-15196: invalid ASM block header on disk [disk_name]

数据库实例报错：
ORA-00600: internal error code, arguments: [kfgPerformRecovery_1]

ASM告警日志中的典型错误：
WARNING: Failed to read from disk group XXX
ERROR: checksum failure in block

使用 kfed 验证时的直接提示：
kfed: checksum error in block

数据库访问ASM文件时的错误：
ORA-01578: ORACLE data block corrupted
ORA-01110: data file XXX