ASM 翻译系列第十二弹:ASM Internal amdu - ASM Metadata Dump Utility

原文: ASM disk header
作者: Bane Radulovic
译者:庄培培,沃趣科技数据库售前工程师,主要负责数据库平台架构方案设计、产品验证测试。
审校:魏兴华
责编:钱曙光

amdu - ASM Metadata Dump Utility

ASM Metadata Dump Utility,即ASM元数据导出工具,它的简写amdu更被人所熟知,常被Oracle技术支持人员和Oracle开发人员用来诊断和解决ASM故障。它能输出ASM的元数据信息并且从ASM磁盘组中抽取元数据和数据文件。 amdu工具不依赖于ASM实例或者ASM磁盘组的状态,所以它能在ASM实例关闭和磁盘组未挂载的情况下正常使用,它甚至能在ASM磁盘出现故障或者不可见的场景下使用。

Use amdu to extract a controlfile from a mounted disk group

在接下来的第一个例子中,我们将以一个处于mount状态的磁盘组为例,使用amdu提取数据库BR的一个控制文件。

通过asmcmd的find命令结合–type参数,指定查找文件类型为controlfile的文件,以下输出列出了所有找到的控制文件的位置:

$ asmcmd find --type controlfile + "*"
+DATA/ASM/CONTROLFILE/cfcopy.268.734178331
+DATA/BR/CONTROLFILE/Current.276.723906721
+DATA/BR/CONTROLFILE/Current.285.723908117
+DATA/BR/CONTROLFILE/Current.294.723912823
+DATA/ORCL/CONTROLFILE/Current.260.715782325
+DATA/cfcopy
+RECO/BR/CONTROLFILE/Current.256.723906723
+RECO/BR/CONTROLFILE/Current.260.723908117
+RECO/BR/CONTROLFILE/Current.264.723912823

以上输出我们可以知道,在DATA磁盘组和RECO磁盘组分别存放了BR数据库控制文件的三个副本。这里以提取DATA磁盘组的Current.276.723906721控制文件为例。

首先我们看下DATA磁盘组有哪些磁盘

$ asmcmd lsdsk -G DATA
Path
ORCL:DISK1
ORCL:DISK2

DATA磁盘组共有两块磁盘-DISK1和DISK2,名字都是以ORCL为前缀的ASMLIB磁盘。严格意义上,并不需要知道具体的磁盘名,只需要查找ASM_DISKSTRING参数值所定义的目录即可。

我们接着用amdu工具将控制文件从DATA磁盘组提取到文件系统上

$ cd /tmp
$ amdu -diskstring="ORCL:*" -extract DATA.276 -output control.276 -noreport -nodir
AMDU-00204: Disk N0001 is in currently mounted diskgroup DATA
AMDU-00201: Disk N0001: 'ORCL:DISK1'
$ ls -l control.276
-rw-r--r-- 1 grid oinstall 9748480 Sep 22 22:42 control.276

此命令相关参数的含义如下:

  • diskstring: 使用磁盘的全路径或者是ASM_DISKSTRING参数值
  • extract: 磁盘组名.ASM文件序号
  • output:提取的输出文件(当前目录下)
  • noreport:不输出amdu的执行过程
  • nodir:不创建dump目录

Use amdu to extract a datafile from a dismounted disk group

上例中从一个已挂载的磁盘组上提取控制文件的过程简单明了。但在实际工作中,可能有客户提出要求从一个未挂载的磁盘组中提取一个重要数据文件,同时并不知道数据文件名,也没有备份。以下是一个具体的例子,演示了整个操作和分析过程。

本例的目标是使用amdu工具从一个不能被挂载的DATA磁盘组中提取一个数据文件,文件名字中包含NSA。这首先意味着在这里sqlplus和asmcmd工具都不能使用。

首先使用amdu工具对DATA磁盘组做一份元数据的完整dump。

$ cd /tmp
$ amdu -dump DATA -noimage
amdu_2011_09_22_22_57_05/
$ cd amdu_2011_09_22_22_57_05
$ ls -l
total 28
-rw-r--r-- 1 grid oinstall 5600 Sep 22 22:57 DATA.map
-rw-r--r-- 1 grid oinstall 10462 Sep 22 22:57 report.txt

在本例中amdu创建了dump目录并产生了两个文件。report.txt文件包含主机、amdu命令及使用的参数、DATA磁盘组可能的成员磁盘和这些磁盘上的AU信息。report.txt文件内容如下

$ more report.txt
-*-amdu-*-
******************************* AMDU Settings ********************************
ORACLE_HOME = /u01/app/11.2.0/grid
System name: Linux
Node name:
Release: 2.6.18-128.4.1.0.1.el5
Version: #1 SMP Tue Aug 4 15:10:25 EDT 2009
Machine: i686
amdu run:
Endianess: 1
...
----------------------------- DISK REPORT N0001 ------------------------------
Disk Path: ORCL:DISK1
Unique Disk ID:
Disk Label: DISK1
Physical Sector Size: 512 bytes
Disk Size: 4886 megabytes
Group Name: DATA
Disk Name: DISK1
Failure Group Name: DISK1
Disk Number: 0
Header Status: 3
Disk Creation Time: 2010/03/01 15:07:47.135000
Last Mount Time: 2011/09/02 15:35:52.676000
Compatibility Version: 0x0b200000(11020000)
Disk Sector Size: 512 bytes
Disk size in AUs: 4886 AUs
Group Redundancy: 1
Metadata Block Size: 4096 bytes
AU Size: 1048576 bytes
Stride: 113792 AUs
Group Creation Time: 2010/03/01 15:07:46.819000
File 1 Block 1 location: AU 2
OCR Present: NO
...
************************** SCANNING DISKGROUP DATA ***************************
Creation Time: 2010/03/01 15:07:46.819000
Disks Discovered: 2
Redundancy: 1
AU Size: 1048576 bytes
Metadata Block Size: 4096 bytes
Physical Sector Size: 512 bytes
Metadata Stride: 113792 AU
Duplicate Disk Numbers: 0
---------------------------- SCANNING DISK N0001 -----------------------------
Disk N0001: 'ORCL:DISK1'
Allocated AU's: 2563
Free AU's: 2323
AU's read for dump: 34
Block images saved: 6661
Map lines written: 34
Heartbeats seen: 0
Corrupt metadata blocks: 0
Corrupt AT blocks: 0
...

DATA.map文件包含数据分布信息。它的内容十分神秘,但对于我们本次的操作目标十分重要。

$ more DATA.map
N0001 D0000 R00 A00000000 F00000000 I0 E00000000 U00 C00256 S0000
B0000000000
N0001 D0000 R00 A00000001 F00000000 I0 E00000000 U00 C00256 S0000
B0000000000
N0001 D0000 R00 A00000002 F00000001 I0 E00000000 U00 C00256 S0000
B0000000000
N0001 D0000 R00 A00000003 F00000003 I0 E00000001 U00 C00256 S0000
B0000000000
N0001 D0000 R00 A00000004 F00000003 I0 E00000011 U00 C00256 S0000
B0000000000
...
N0001 D0000 R00 A00000234 F00000267 I1 E00000000 U00 C00001 S0000
B0000000000
...
N0004 D0001 R00 A00001512 F00000292 I1 E00000000 U00 C00001 S0000
B0000000000
N0004 D0001 R00 A00002304 F00000290 I1 E00000000 U00 C00003 S0000
B0000000000
N0004 D0001 R00 A00002643 F00000264 I1 E00000000 U00 C00001 S0000
B0000000000

一眼看到就感觉有价值的内容是A和F起始的两列。比如,A00000234代表本行是关于AU 234. F00000267代表本行与序号267的ASM文件相关。

重新回到查找NSA数据文件的目标。ASM序号6的元数据文件是alias别名目录,这是查找目标的起点。通过DATA.map文件,能找到序号6的ASM元数据文件的所有AU。

$ grep F00000006 DATA.map
N0004 D0001 R00 A00000008 F00000006 I0 E00000000 U00 C00256 S0000
B0000000000

通过查找定位到与该元数据文件相关的AU记录只有一行。这说明磁盘组内的文件不多,它们所有的别名都只存放在一个AU内,同时别名目录元数据文件存放在磁盘1(D0001)的AU 8(A00000008)。 从前面report.txt的记录中知道,磁盘1指的是ORCL:DISK2并且它的AU大小是1MB。通过kfed工具来查看alias目录文件。

$ ls -l /dev/oracleasm/disks/DISK2
brw-rw---- 1 grid asmadmin 8, 6 Aug 24 14:38 /dev/oracleasm/disks/DISK2
$ kfed read /dev/oracleasm/disks/DISK2 aun=8 | more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR
...

kfed的输出信息中kfbh.type验证了这是一个alias目录文件。下一步查找名字包含NSA的数据文件:

for (( i=0; i<256; i++ ))
do
kfed read /dev/oracleasm/disks/DISK2 aun=8 blkn=$i | grep -1 NSA
done

命令的输出内容如下:

kfade[15].entry.refer.incarn: 0 ; 0x4a4: A=0 NUMM=0x0
kfade[15].name: NSA_TN_DATA ; 0x4a8: length=11
kfade[15].fnum: 267 ; 0x4d8: 0x0000010b

名字包含NSA的数据文件是NSATNDATA,它的ASM文件序号是267.接下来可以进一步提取数据文件:

$ amdu -diskstring="ORCL:*" -extract DATA.267 -output NSA_TN_DATA.267 -noreport -nodir
$ ls -l
total 102544
-rw-r--r-- 1 grid oinstall 5600 Sep 22 22:57 DATA.map
-rw-r--r-- 1 grid oinstall 104865792 Sep 22 23:42 NSA_TN_DATA.267
-rw-r--r-- 1 grid oinstall 10462 Sep 22 22:57 report.txt

使用这个文件我们能够做些什么呢?好吧,如果能提取到数据库控制文件,system和sysaux系统表空间数据文件,就可以用这些文件来打开数据库。还可能把这个文件“迁移”到别的数据库,甚至可能用DUL这样的非常规工具来提取数据文件内的数据。

需要注意是amdu提取的可能是有损坏或者是已破坏的文件,这取决于文件本身是否有损坏。对于那些由于元信息损坏或者丢失儿导致的不能呗mount的磁盘组,也有可能数据文件是好的,这样情况下同样可以使用amdu来抽取到完好的数据文件。
但是记住这个过程不能用来替代备份。

The amdu dump triggered on an error

从ASM的11.2.0.3版本开始,ORA-600 [kfd…]类似的错误可能会触发一次自动的amdu的dump操作。当这种类型的错误发生时,除了错误信息会记录到ASM的Alert日志外,还会有信息提示做了一次amdu的dump操作。dump的文件会放在相应的诊断目录下。

Conclusion

amdu是一个非常称手的工具,但它对用户或者DBA的意义相对有限。但是如果知道amdu的作用,在与Oracle技术支持人员交流中还是非常有帮助的。

译者注:除了从ASM的alias文件目录中获取数据文件的名称外,还可以从控制文件中获得,有了控制文件就能够将数据库启动到mount状态查看v$datafile视图,进而获取数据文件名称。但是控制文件中记录的信息可能只是个alias,如果是这种情况,那么还是需要从alias目录中定位到真正的数据文件名称。

ASM翻译系列导读:

  • ASM 翻译系列第十二弹:ASM Internal amdu - ASM Metadata Dump Utility
  • ASM 翻译系列第十一弹:高级知识 Offline or drop?
  • ASM 翻译系列第十弹:ASM Internal ASM DISK header
  • ASM 翻译系列第九弹:ASM工具箱
  • ASM 翻译系列第八弹:ASM Internal ASM file extent map
  • ASM 翻译系列第七弹:高级知识 How many partners?
  • ASM 翻译系列第六弹:高级知识如何映射asmlib管理的盘到它对应的设备名
  • ASM 翻译系列第五弹:高级知识ASM元数据概述
  • ASM 翻译系列第四弹:高级知识kfed元数据编辑器
  • ASM 翻译系列第三弹:ASM disk的基础知识
  • ASM 翻译系列第二弹:ASM 12C 版本新特性
  • ASM 翻译系列第一弹:基础知识 ASM AU,Extents,Mirroring 和 Failgroups

你可能感兴趣的:(ASM 翻译系列第十二弹:ASM Internal amdu - ASM Metadata Dump Utility)