如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
Oracle Database – 企业版 – 版本10.2.0.1到12.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).
Comment