oracle数据库用了asm asm加载一个磁盘组出现ora-15196 invaild asm

ASM数据恢复ORA-15196 invalid ASM block header [kfcc] [check_kfbh]错误解析

ORA-15196: invalid ASM block header [kfcc] [check_kfbh] [325] [2147483650] [2170461157 != 2170461165]

是当ASM读取到无效的asm block header时的报错，相关的BUG NOTE如下：

check_kfbh的存在时为了检验块的一致性 ，会对整个块做一个32 bit xor 来对比现有check_kfbh，有点象block的checksum

The field check_kfbh is adjusted to ensure that a 32 bit xor of the whole block will be zero Check values are always calculated before writing a

block to disk, but may not be accurate for a block in the buffer cache In this example the check value is “8A 8B D0 AE” but since this is little

endian the actual value is “0xAED08B8A

对于该问题 建议：

1、首先要检查 OS是否存在IO丢失的问题，例如 AIX上执行 errpt ，Linux查看os log 和dmesg

2、 检查RAC的多个节点上存储设备名是否一致

3、 考虑执行 ' alter diskgroup check norepair'来检查ASM diskgroup

4、112中如果遇到上述情况会自动使用amdu工具dump ASM disk其trace一般在ASM对应的user dump下 ，如NOTE: AMDU dump of disk group MAC created at /oracle/diag/asm/+asm/+ASM3/trace， 整个AMDU trace里包含了很有用的信息，如果存在大量的AMDU-00209: Corrupt block found: Disk N0072 AU [26127] block [94] type [0]信息，和看到 Corrupt metadata blocks: 320 大量损坏的元数据块， 则说明该问题一般是由于 OS层或者磁盘/存储硬件层引起的，因为不太可能有ASM的bug 会造成这么大量的损坏， 解释成丢失更新 Lost Update也不合理

5、实际上如果你和我一样检阅过上面全部的BUG Note，你会发现没有个BUG note是最终定位为real bug的，这些SR/Bug Note最终要么不了了之，要么查出来确实是OS或者硬盘/存储有问题；所以对于这个问题提交SR的效率很低， 往往找OS和存储厂商一起检查更有效率

6、如果你真的遇到了该问题，那么如果坏掉的元数据块(metadata block)比较少的话，可以请相关的ASM专家手工帮你修复，具体也可以找ASKMACLEAN专业ORACLE 数据库修复团队成员帮您恢复。切记不要在无备份ASM header的情况下 *** 作，否则可能丢失恢复数据的最后一线希望。

ASM是Oracle10gR2中为了简化Oracle数据库的管理而推出来的一项新功能，这是Oracle自己提供的卷管理器，主要用于替代 *** 作系统所提供的LVM，它不仅支持单实例，同时对RAC的支持也是非常好。ASM可以自动管理磁盘组并提供有效的数据冗余功能。使用ASM（自动存储管理）后，数据库管理员不再需要对ORACLE中成千上万的数据文件进行管理和分类，从而简化了DBA的工作量，可以使得工作效率大大提高。详细步骤：7924376

以上就是关于oracle数据库用了asm asm加载一个磁盘组出现ora-15196 invaild asm全部的内容，包括:oracle数据库用了asm asm加载一个磁盘组出现ora-15196 invaild asm、ORACLE 11g单机数据库安装，应该选择文件系统还是ASM，为什么、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！