amdu - ASM Metadata Dump Utility

ASM Metadata Dump Utility, or ASM metadata export tool, its abbreviation amdu is more well known, often used by Oracle technical support personnel and Oracle developers to diagnose and solve ASM failures. It can output metadata information of ASM and extract metadata and data files from ASM disk group. The amdu tool does not depend on the status of the ASM instance or the ASM disk group, so it can be used normally when the ASM instance is closed and the disk group is not mounted. It can even be used in situations where the ASM disk fails or is invisible.

Use amdu to extract a controlfile from a mounted disk group

In the next first example, we will use amdu to extract a control file from the database BR, taking a mount-state disk group as an example.

Combining the find command of asmcmd with the type parameter, the file with the control file type is specified. The following output lists the locations of all the control files found:

$ 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

As we can see from the above output, three copies of BR database control files are stored in DATA disk group and RECO disk group respectively. Here we take the Current.276.723906721 control file extracted from DATA disk group as an example.

First, let's look at what disks the DATA disk group has.

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

DATA disk group has two disks - DISK1 and DISK2. The names are ASMLIB disks prefixed with ORCL. Strictly speaking, you don't need to know the specific disk name, just look up the directory defined by the ASM_DISKSTRING parameter value.

We then use the amdu tool to extract the control files from the DATA disk group to the file system.

$ 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

The meaning of the command parameters is as follows:

• diskstring: Full path using disk or ASM_DISKSTRING parameter value
• extract: Disk group name. ASM file number
• Output: Extracted output file (under current directory)
• noreport: Execution process without outputting amdu
• nodir: Do not create dump directories

Use amdu to extract a datafile from a dismounted disk group

In the previous example, the process of extracting control files from a mounted disk group is straightforward. However, in practice, there may be customers who request to extract an important data file from an unmounted disk group without knowing the name of the data file or backup. The following is a concrete example to illustrate the whole operation and analysis process.

The goal of this example is to use the amdu tool to extract a data file from a DATA disk group that cannot be mounted, and the file name contains NSA. This first means that neither sqlplus nor asmcmd tools can be used here.

First, we use amdu tool to make a complete dump of metadata for DATA disk group.

$ 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

In this case, amdu creates the dump directory and produces two files. The report.txt file contains the host, the amdu command and the parameters used, the possible member disks of the DATA disk group, and AU information on those disks. The report.txt file is as follows

$ 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
...

The DATA.map file contains data distribution information. Its content is very mysterious, but it is very important for our operation objectives.

$ 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

What feels valuable at first sight is the two columns starting from A and F. For example, A00000234 represents our bank and is related to the ASM file of AU 234. F00000267 represents our bank and serial number 267.

Return to the target of finding the NSA data file. The metadata file of ASM serial number 6 is alias alias alias directory, which is the starting point for finding the target. Through DATA.map file, all AU s of ASM metadata file with serial number 6 can be found.

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

Only one line of AU records related to the metadata file is located by lookup. This means that there are not many files in the disk group. All of their aliases are only stored in one AU, while the alias directory metadata files are stored in AU 8(A00000008) of disk 1(D0001). As you can see from the previous report.txt record, disk 1 refers to ORCL:DISK2 and its AU size is 1MB. View alias directory files through the kfed tool.

$ 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
...

kfbh.type in the output information of kfed verifies that this is an alias directory file. Next, find the data file whose name contains NSA:

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

The output of the command is as follows:

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

The data file whose name contains NSA is NSATNDATA, and its ASM file number is 267. Next, the data file can be further extracted:

$ 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

What can we do with this file? Well, if you can extract database control files, system and sysaux system table space data files, you can use these files to open the database. It may also "migrate" this file to other databases, or even use unconventional tools such as DUL to extract data from data files.

It should be noted that amdu extracts files that may be damaged or damaged, depending on whether the file itself is damaged. For those disk groups that cannot be mount ed due to meta-information damage or loss, it is also possible that the data file is good. In this case, amdu can also be used to extract intact data files.
But remember that this process cannot be used as a substitute for backup.

The amdu dump triggered on an error

Starting with version 11.2.0.3 of ASM, ORA-600 [kfd... A similar error may trigger an automatic dump operation for amdu. When this type of error occurs, in addition to the error information recorded in the Alert log of ASM, there will also be information prompting for a dump operation of amdu. Dump files are placed in the corresponding diagnostic directory.

Conclusion

Amdu is a very handy tool, but its meaning to users or DBA s is relatively limited. But knowing the role of amdu can be very helpful in communicating with Oracle technical support staff.

Translator's Note: In addition to getting the name of the data file from the alias file directory of ASM, you can also get the name of the data file from the control file. With the control file, you can start the database to mount state to view the view of V $data file, and then get the name of the data file. However, the information recorded in the control file may only be an alias, if this is the case, then you still need to locate the real data file name from the alias directory.