该问题的典型症状如下:
- 在低于版本11.2的RAC环境中发生
- 当从一个已经mount的diskgroup中增加或者drop磁盘时发现alert.log中出现ORA-15196错误
- 一般在alert.log中是显示blk=2即block number=2的metadata block出现checksum错误
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
例如:
WARNING: cache read a corrupted block gn=27 dsk=3 blk=2 from disk 3 NOTE: a corrupted block was dumped to /oracle/product/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_551.trc ERROR: cache failed to read gn=27 dsk=3 blk=2 from disk(s): 3 ORA-15196: invalid ASM block header [kfc.c:9194] [check_kfbh] [2147483651] [2] [2158748224 != 4194727149] System State dumped to trace file /oracle/product/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_551.trc NOTE: cache initiating offline of disk 3 group 27
- 这里的blk=2 一般代表allocation table
- 如果blk=#不是2则可能与本文档描述的现象不一致
通过16进制dump可以看到在第三个块中出现etoV的字样,例如:
dd if=/tmp/etoV.dd bs=4096 skip=2 count=1 | hexdump -C | grep etoV 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 1.6e-05 seconds, 256 MB/s 00000600 65 74 6f 56 03 00 00 00 01 03 0b 01 00 00 00 00 |etoV............| 或者 $ dd if=/tmp/etoV.dd bs=4096 skip=2 count=1 | od -t xz | grep etoV 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 1.7e-05 seconds, 241 MB/s 0003000 566f7465 00000003 010b0301 00000000 >etoV............<
问题发生的原因是可能是由于OS级别的磁盘路径配置错误,常见于系统重启后,导致CRS启动时将ASM 磁盘错认为是vote disk device,并将vote disk信息写入到错误的设备上。
对于该问题 如果是high/normal redundancy则易于解决, 但如果是 EXTERNAL redundancy则可能需要专业人员手工patch asm disk来修复了。
如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!
Comment