归零的ASM块

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:service@parnassusdata.com

 

症状

1. ASM在警报日志文件中报告一个或几个损坏的块,以及错误ORA-15196

警告: 缓存读取损坏快: group=1(<DISKGROUP>) dsk=0 blk=1 disk=0 (<DISK>) incarn=3916383599 au=0 blk=1 count=1
Errors in file <trace file>

ORA-15196:不可用的ASM 块头 [kfc.c:26076] [endian_kfbh] [2147483648] [1] [0 != 1]
注意: CRSDG 组中的损坏快被转储到<trace file>

2. AMDU在文件report.text中报告元数据损坏块:

———————— SUMMARY FOR DISKGROUP <DISKGROUP>————————
Allocated AU’s: 253711
Free AU’s: 145649
AU’s read for dump: 15
Block images saved: 1273
Map lines written: 15
Heartbeats seen: 0
Corrupt metadata blocks: 768  ——>  HERE
Corrupt AT blocks: 2        ——>  HERE

3. kfed揭示了块,其中几个为零:

$kfed read <disk1> aunum=0 blknum=1

kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                           0 ; 0x00c: 0x00000000
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
2B98D2EFF400 00000000 00000000 00000000 00000000  […………….]
Repeat 255 times

$kfed read <disk2> aunum=0 blknum=2

kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                           0 ; 0x00c: 0x00000000
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
2B2D30FBB400 00000000 00000000 00000000 00000000  […………….]
Repeat 255 times

$kfed read <disk3> aunum=0 blknum=3

kfbh.endian:                          0 ; 0x000: 0x00
kfbh.hard:                            0 ; 0x001: 0x00
kfbh.type:                            0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt:                          0 ; 0x003: 0x00
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       0 ; 0x008: file=0
kfbh.check:                           0 ; 0x00c: 0x00000000
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
2B9D91687400 00000000 00000000 00000000 00000000  […………….]
Repeat 255 times

上面显示的输出,是从不同磁盘组的不同磁盘中收集来的。

发展发现块1,2,3,4都是零。

原因

这种情况没什么特别的原因,但由于ASM不以那样的方式更新ASM元数据块,大多数时候这种情况是由于:

1. 硬件问题

2. DBASM实例外部的项目

解决方案

不幸的是,若几个ASM元数据块被零代替,这种情况便无法恢复。唯一的选择是重建磁盘组并还原数据库备份。

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569