ORA-15066 
How to Identify and Diagnostic ASM Disk Overlapping by an OS Filesystem (ASM Disk Overlapping : Scenario #3)

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

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

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

 

适用于:

Oracle Database – Enterprise Edition – 版本10.2.0.112.1.0.2 [Release 10.2 to 12.1]
本文信息适用于任何平台。

症状

1) 本文提供了有关如何通过操作系统的文件系统来识别和诊断ASM磁盘重叠(overlap)的例子。

2) 该重叠行为是破坏性操作,它肯定破坏了ASM磁盘。

3) 例如

3.1) 由于下一个错误,磁盘组被dismount

ORA-15335: ASM metadata corruption detected in disk group ‘DATA’
ORA-15130: diskgroup “DATA” is being dismounted
ORA-15066: offlining disk “DATA_0003” in group “DATA” may result in a data loss
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483651] [48] [0 != 1]
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483651] [48] [0 != 1]


3.2)
受影响的磁盘成员在磁盘头中报告下一个非ASM元数据:

 0602100 51e2b7f6 00ed4e00 00000000 00000001 >...Q.N..........<
 0602120 00000000 0000000b 00000100 0000003c >............<...<
 0602140 00000242 0000007b 5d8468e7 6147782a >B...{....h.]*xGa<
 0602160 d17851a2 327552e2 00000000 00000000 >.Qx..Ru2........<
 0602200 00000000 00000000 3130752f 91a4f000 >......../u01....<   <(====== ****** Here *******
 0602220 ff8808e4 d5104cff 000000ac 00000100 >.....L..........<
 0602240 00000000 00000000 00000000 09d18000 >................<

原因

1) 受影响的磁盘的dd dump 显示并确认通过mount“/u01”文件系统ASM磁盘被重叠:

0602100 51e2b7f6 00ed4e00 00000000 00000001 >...Q.N..........<
 0602120 00000000 0000000b 00000100 0000003c >............<...<
 0602140 00000242 0000007b 5d8468e7 6147782a >B...{....h.]*xGa<
 0602160 d17851a2 327552e2 00000000 00000000 >.Qx..Ru2........<
 0602200 00000000 00000000 3130752f 91a4f000 >......../u01....< 0602220 ff8808e4 d5104cff 000000ac 00000100 >.....L..........<
 0602240 00000000 00000000 00000000 09d18000 >................<

2) 比较常规OS文件系统的OS元数据显示相同的元数据信息:

2.1) 有:/u02” filesystem (如示例):

[ebernal@dbaasm mine]$ df -k /u02
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda3            106505124  39067164  61940520  39% /u02

2.2) 然后,dump包含文件系统(“/u02”)的相关块设备(“/dev/sda3”)的头50MB

[root@dbaasm mine]# dd if=/dev/sda3  of=./sda3_u02.dump bs=1048576 count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.047495 seconds, 1.1 GB/s

[root@dbaasm mine]# ls -l
total 51256
-rw-r–r– 1 root root 52428800 May 30 10:45 sda3_u02.dump

[root@dbaasm mine]# chown ebernal:oinstall sda3_u02.dump

[root@dbaasm mine]# ls -l
total 51256
-rw-r–r– 1 ebernal oinstall 52428800 May 30 10:45 sda3_u02.dump

2.3) 结果确认它报告了完全相同的OS元数据:

[ebernal@dbaasm mine]$ dd if=sda3_u02.dump bs=4KB   | …  | grep  /u02
0002160 9573b986 089191a9 3130752f 00000000  >..s…../u02….<

解决方案

a) 如果这是一个外部冗余磁盘组(创建文档ID 1910315.1),则受影响的磁盘组需要被重建且由于受影响的磁盘组由OS文件系统重叠,数据库文件从备份中还原,换句话说,损坏的发生在Oracle外,因为在OS文件系统重叠中ASM磁盘的数据,因此不能被修复。

b) 普通   冗余磁盘组,只要替换受影响的磁盘(参见文档 ID 946213.1)。

参考

NOTE:946213.1 - How To Add Back An ASM Disk or Failgroup (Normal or High Redundancy) After A Transient Failure Occurred Or When The DISK_REPAIR_TIME Attribute Expired (10.1 to 12.1)?
 NOTE:1526819.1 - How To Reorganize A Normal or High Redundancy ASM Diskgroup With An Uneven Number Of Disks Members In The Failgroups (ORA-15041).
 NOTE:1675152.1 - Collecting The Required Information For Support To Validate & Troubleshooting ASM Diskgroup Corruptions.
 NOTE:1673750.1 - KFED Reports “KFBTYP_INVALID” & OS Metadata [EFI PART] In ASMLIB Disk /ASM disk Member (ASM Disk Overlapping : Scenario #1).
 NOTE:1678139.1 - KFED Reports “KFBTYP_INVALID” & OS Metadata [LVM2 001] In "/dev/emcpower" Disk /ASM disk Member (ASM Disk Overlapping : Scenario #2). 
 NOTE:1910315.1 - How to Create a Normal Redundancy Diskgroup Best Practices

关注刘相兵的新浪微博

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

Speak Your Mind

沪公网安备 31010802001379号

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