This is a database of a netizen in the 11g ASM environment. The ASM metadata is damaged, and DiskGroup cannot be mounted. However, we are lucky to store images. Even so, it is said that it took more than one day for storage engineers to recover. This is unacceptable for our business systems.
I will post the case information of this database for your reference! (Note: We provide a variety of database solutions. For details, see Yunhe and emo)
WARNING: cache read a previous UPT block: group = 3 (DATAVG) dsk = 27 blk = 1 disk = 27 (DATAVG_0018) incarn = 4042368416 au = 0 blk = 1 count = 1
Errors in file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_ora_2711.trc:
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
NOTE: a brief upted block from group DATAVG was dumped to/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_ora_2711.trc
WARNING: cache read (retry) a Bytes UPT block: group = 3 (DATAVG) dsk = 27 blk = 1 disk = 27 (DATAVG_0018) incarn= 4042368416 au = 0 blk = 1 count = 1
Errors in file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_ora_2711.trc:
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
ERROR: cache failed to read group = 3 (DATAVG) dsk = 27 blk = 1 from disk (s): 27 (DATAVG_0018)
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
NOTE: cache initiating offline of disk 27 group DATAVG
NOTE: process _ user2711 _ + asm1 (2711) initiating offline of disk 27.4042368416 (DATAVG_0018) with mask 0x7e in group 3
WARNING: Disk 27 (DATAVG_0018) in group 3 in mode 0x7f is now being taken offline on ASM inst 1
NOTE: initiating PST update: grp = 3, dsk = 27/0 xf0f1a5a0, mask = 0x6a, op = clear
Wed Jan 28 10:41:11 2015
GMON updating disk modes for group 3 at 13 for pid 36 and osid 2711
ERROR: Disk 27 cannot be offlined, since diskgroup has external redundancy.
ERROR: too offline disks in PST (grp 3)
Wed Jan 28 10:41:11 2015
NOTE: cache dismounting (not clean) group 3/0xB80155A0 (DATAVG)
NOTE: messaging CKPT to quiesce pins Unix process pid: 3013, image: oracle @ rsdb01 (B000)
Wed Jan 28 10:41:11 2015
NOTE: halting all I/OS to diskgroup 3 (DATAVG)
Wed Jan 28 10:41:11 2015
NOTE: LGWR doing non-clean dismount of group 3 (DATAVG)
NOTE: LGWR sync ABA = 114.216 last written ABA 114.216
WARNING: Offline of disk 27 (DATAVG_0018) in group 3 and mode 0x7f failed on ASM inst 1
System State dumped to trace file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_ora_2711.trc
Wed Jan 28 10:41:11 2015
Kjbdomdet send to inst 2
Detach from dom 3, sending detach message to inst 2
Wed Jan 28 10:41:11 2015
List of instances:
1 2
Dirty detach reconfiguration started (new ddet inc 1, cluster inc 20)
Global Resource Directory partially frozen for dirty detach
* Dirty detach-domain 3 invalid = TRUE
1152 GCS resources traversed, 0 canceled
Dirty Detach Reconfiguration complete
Wed Jan 28 10:41:11 2015
WARNING: dirty detached from domain 3
NOTE: cache dismounted group 3/0xB80155A0 (DATAVG)
SQL> alter diskgroup DATAVG dismount force/* ASM SERVER */
Wed Jan 28 10:41:12 2015
ERROR: ORA-15130 in COD recovery for diskgroup 3/0xb80155a0 (DATAVG)
ERROR: ORA-15130 thrown in RBAL for group number 3
Errors in file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_rbal_2389.trc:
ORA-15130: diskgroup "DATAVG" is being dismounted
ERROR: ORA-15130 in COD recovery for diskgroup 3/0xb80155a0 (DATAVG)
ERROR: ORA-15130 thrown in RBAL for group number 3
Errors in file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_rbal_2389.trc:
ORA-15130: diskgroup "DATAVG" is being dismounted
ERROR: ORA-15130 in COD recovery for diskgroup 3/0xb80155a0 (DATAVG)
ERROR: ORA-15130 thrown in RBAL for group number 3
Errors in file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_rbal_2389.trc:
ORA-15130: diskgroup "DATAVG" is being dismounted
NOTE: AMDU dump of disk group DATAVG created at/u01/app/grid/diag/asm/+ ASM1/trace
NOTE: cache deleting context for group DATAVG 3/0xb80155a0
GMON dismounting group 3 at 14 for pid 37, object ID 3013
NOTE: Disk in mode 0x8 marked for de-assignment
.......
NOTE: Disk in mode 0x8 marked for de-assignment
NOTE: Disk in mode 0x8 marked for de-assignment
SUCCESS: diskgroup DATAVG was dismounted
SUCCESS: alter diskgroup DATAVG dismount force/* asm server */
ERROR: PST-initiated mandatory dismount of group DATAVG
Wed Jan 28 10:41:20 2015
NOTE: diskgroup resource ora. DATAVG. dg is offline
Wed Jan 28 10:41:26 2015
NOTE: ASM client rsdb1: rsdb disconnected unexpectedly.
NOTE: check client alert log.
NOTE: Trace records dumped in trace file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_ora_2667.trc
From the above error, we can judge that the asm diskgroup cannot be mounted. The cause of the error is as follows:
WARNING: cache read a previous UPT block: group = 3 (DATAVG) dsk = 27 blk = 1 disk = 27 (DATAVG_0018) incarn = 4042368416 au = 0 blk = 1 count = 1
Errors in file/u01/app/grid/diag/asm/+ ASM1/trace/+ ASM1_ora_2711.trc:
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
According to the information above, the 27th block of the 0th AU of the 1st disk of the DATAVG disk group is damaged. In fact, this is because the disk header is damaged.
The following is a simple explanation of ORA-15196 errors:
ORA-15196: invalid ASM block header [kfc. c: 26076] [hard_kfbh] [2147483675] [1] [0! = 130]
[Kfc. c: 26076]: indicates that the error occurs in line 26,076th of the code running kfc. c.
[Hard_kfbh]: indicates the type of check failure
[2147483675]: indicates the file number.
[1]: block number
[0! = 130]: indicates the value of this field. The current value is 0. The detection result is actually 130.
In fact, once such an error occurs, the ASM metadata damages not only the disk header. After our judgment, at least the first 4 MB of ASM metadata has been
Damaged. In this case, AMDU may not be used to extract data files.
Generally, for DiskGroup of external, if the ASM metadata of the previous 42M is not completely damaged, the data in DiskGroup is easy to get out.
If the damage is serious, you may only need to use the database extraction tool to scan the disk. At present, DUL or ODU can solve this situation perfectly.
If you encounter a similar database fault, please contact us immediately!