如何确认和诊断被 OS 文件系统覆盖的ASM 磁盘 (ASM 磁盘覆盖 : Scenario #3)

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

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

服务热线 : 13764045638    QQ号:47079569    邮箱:[email protected]

 

Oracle Database – 企业版版本10.2.0.112.1.0.2 [版本10.2 12.1]
本文献的信息适用于任何平台。

症状

1) 本文献提供了一个例子,关于如何如何确认和诊断被 OS 文件系统覆盖的ASM 磁盘。

2) 这个覆盖是一个破坏性的操作,一定会损坏ASM 磁盘。

3) 例如

3.1) 磁盘组因为下列错误卸载:

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) 通过安装“/u01”文件系统,受影响磁盘的dd 转储显示和确认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元数据,显示相同的元数据信息:

2.1) : “/u02” 文件系统 (例如):

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

2.2) 然后,转储包含文件系统 (“/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) 如果这是一个外部冗余磁盘组(参考 Doc ID 1910315.1),那么需要重建受影响的磁盘组,需要从备份恢复数据库文件,因为受影响的磁盘被 OS 文件系统覆盖,换句话说,损坏发生在Oracle之外,它不能得到修复因为 OS 文件系统覆盖了ASM 磁盘的数据。

b)在普通货高冗余磁盘组上,仅替换受影响的磁盘组(参考Doc ID 946213.1).


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *