咨询热线： 13764045638 7 x 24 在线支持！
- You are here: 首页 > 博客 > PDSERVICE的博客 > Oracle ASM AMDU functionality and usage
Oracle ASM AMDU functionality and usage
Oracle ASM AMDU functionality and usage
If you cannot recover data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.
Use this document to understand AMDU functionality.
AMDU functionality and usage
1. Dump metadata from ASM disks to the OS file system for later analysis.
2. Extract the contents of an ASM file and write it to an OS file system even if the diskgroup is not mounted.
3. Print metadata blocks based on the C structures in the blocks, or in hex.
1] Discoverdisks: This uses ASM discovery to find a set of disks. The headers are read to determine which disks are in which diskgroups. The disks are scanned and the results of the discovery are put in the report file.
2] Scan disks: The allocation tables of disks are scanned. Based on the allocation table entries and command line options, interesting blocks are written to image files. Map files are created describing the interesting AU's and where they were written to the image files.
3] Extractfiles: The extent maps of files to extract are sorted. The file data is read from the ASM disks and written to output files.
Four types of ouptut files are created by AMDU. They are all placed in a new dump directory. The file names are automatically generated by AMDU. A new dump directory is created for each run. The name of the directory is based on the time and date to one second resolution.
1] Extracted Files :
One extracted file is created for every file listed under the -extract option on the command line. The extracted file is placed in the dump directory under the name <group>_<number>.f where <group> is the diskgroup name in uppercase, and <number> is the file number specified on the command line.
2] Image Files :
Image files contain block images from the ASM disks. This is the raw data that is copied from the disks. Since there can be a lot of data, and some file systems have problems with large files, an image file is always smaller than 2 gigabytes. When there is more that 2Gb of data, multiple image files are created. An image file may contain data from multiple disks, but only from disks that are part of the same disk group (according to the disk's header). Uninteresting data, such as empty blocks, will not be dumped, so a partial AU might be in the dump. Thus the size of a full image file is not constant
Image file names are constructed from the group name and a sequence number. The form is as follows where GROUP is the group name in uppercase, and is the sequence number including leading zeroes. The first image file has sequence number 0001.
3] Map Files :
Map files are ASCII files that describe the data in the image files for a particular disk group. AMDU creates one map file for each series of image files, i.e. one map file per disk group.Every line has the same fields of the same length. The lines are in the order of the data in the image file, but contain absolute references to the locations in the image file so that they can be sorted into different orders without losing track of where the AU is stored in the image files.
# Disk Report Number (N4): Every disk discovered by shallow discovery is assigned a disk report number. This number is printed in the report file along with information about the disk. Two disks from the same diskgroup with the same disk number will still have different disk report numbers. The first disk reported will have a disk report number of 1.
# Disk number (D4): This is the disk number field extracted from the header. If the disk number is invalid or the header unrecognizable this field is 9999.
# Disk repeat (R2): Normally this is zero. It is possible to find two disks for the same disk number in the same disk group. The first repeat gets a repeat count of 1 for its map file entries.
# Allocation Unit (A8): The AU within the disk where the data was read.If the disk is greater than 100 terabytes and the AU size is one megabyte, then this field could exceed 8 digits.
# File Number (F8): The ASM file that owns the extent. If the number is less than 256 then this is ASM metadata or an ASM registry.
4] Report File :
One report file is generated for every run of the utility without the -directory option (except if -noreport is specified). It is written to “report.txt” in the dump directory. If -nodir is specified the report is written to standard out instead of the dump directory name. Lines are flushed to the report file as soon as they are generated so tail -f can be used to monitor progress.
When AMDU is run with -print and -directory options then no report is generated. Instead an existing report file must be found and parsed. Information in the report file is used instead of discovering the disks. The map file is used to find the blocks to printout, and the block contents are retrieved from the image files.
The report is divided into sections and subsections. Each section begins with a title line. Any errors reported by AMDU are also printed in the report file. Warnings about unexpected conditions are printed in upper case surrounded by " ** "
The following describes the sections in the report file.
# AMDU Setting : The first lines describe the environment where the dump was created. This includes the time
when the report was generated and the endianess of the data in the image files. The host name, platform, and
software version are also included. The following subsections describes all the arguments from the command
line: operations, disk selection, reading control, and output control. This is a report of the settings that result
from the command line parsing, not a copy of the command line.
a] Discovery : This section describes every disk returned by discovery. There is one subsection for each
disk.The title contains the disk report number. This is followed by the information from shallow discovery. If
deep discovery is done for the disk, then the results of deep discovery are reported next. A warning
message may indicate that a disk is being ignored.
b] Sleeping for Heartbeat : Unless the -noheart option is given, a section header is reported containing the time
sleeping for heatbeat detection. This makes it likely that any disks which contain a PST of a mounted
diskgroup will have a heartbeat detected. The section has no lines other than the section header.
c] Diskgroup Scan : There is one section for every disk group encountered by deep discovery and referenced
in either a -dump, -extract or -print option The name of the disk group is in the section header. This is
followed by information gathered about the diskgroup during deep discovery. This includes group wide
parameters from the disk headers such as AU size and creation time.
A disk scan subsection for each scanned disk in the diskgroup follows the header. Disks that are ignored
due to deep discovery and/or command line options, do not have a subsection. The subsection header
includes the disk report number. Some of the information from discovery is repeated for convenience. This is
reported before the scan begins. Error messages and warnings, such as heartbeat detected, may be reported
during the scan. When the scan is complete statistics from the scan are reported. This includes information
about data written to the map and image files. Statistics such as space allocated and free are also reported.
Below command was executed to create the dump of the metadata for the disks in the diskgroup DGD11G.
[oracle@stgrac1 ~]$ amdu -dump DGD11G
AMDU-00204: Disk N0003 is in currently mounted diskgroup DGD11G
AMDU-00201: Disk N0003: '/dev/raw/raw3'
[oracle@stgrac1 ~] cd amdu_2009_07_08_14_37_23/
[oracle@stgrac1 amdu_2009_07_08_14_37_23]$ ls -lrt
-rw-r--r-- 1 oracle dba 7902 Jul 8 14:37 report.txt
-rw-r--r-- 1 oracle dba 7840 Jul 8 14:37 DGD11G.map
-rw-r--r-- 1 oracle dba 97558528 Jul 8 14:37 DGD11G_0001.img
Hence under the directory amdu_2009_07_08_14_37_23 it creates a image file,report
and a map file as shown above.The report.txt file shows the header info of the
disks belonging to diskgroup DGD11G.
----------------------------- DISK REPORT N0003 ---------------------------
Disk Path: /dev/raw/raw3
Physical Sector Size: 512 bytes
Disk Size: 977 megabytes
Group Name: DGD11G
Disk Name: DGD11G_0000
Failure Group Name: DGD11G_0000
----------------------------- DISK REPORT N0004 ---------------------------
Disk Path: /dev/raw/raw4
Physical Sector Size: 512 bytes
Disk Size: 978 megabytes
Group Name: DGD11G
Disk Name: DGD11G_0001
Failure Group Name: DGD11G_0001
Note that disk DGD11G_0000 (/dev/raw/raw3) is referred as N0003 and DGD11G_0001 (/dev/raw/raw4) is referred as N0004.
The below are first few lines as seen from the mapping file.
N0003 D0000 R00 A00000000 F00000000 I0 E00000000 U00 C00256 S0001 B0000000000
N0003 D0000 R00 A00000001 F00000000 I0 E00000000 U00 C00256 S0001 B0001048576
N0003 D0000 R00 A00000002 F00000001 I0 E00000000 U00 C00256 S0001 B0002097152
N0003 D0000 R00 A00000003 F00000002 I0 E00000000 U00 C00256 S0001 B0003145728 >>>>>>>
N0003 D0000 R00 A00000004 F00000003 I0 E00000000 U00 C00256 S0001 B0004194304
We know that the diskdirectory happens to be the file #2 .From the mapping file its evident that the diskdirectory
is situated at Allocation unit number 2
Note : This can also be derived as below .
The last column in the mapping file describe the block offset in the image file. i.e..
Byte offset in Image file : B0003145728
3145728/1048576 (AU Size)=2 i.e..Allocation unit
(In case the result is not a decimal say 2.04 then multiply 0.4 with 1048576 to identify the block number.)
Now execute the below kfed command on image file to identify the disk directory.
$ kfed read DGD11G_0001.img aunum=3 blknum=0 | more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 6 ; 0x002: KFBTYP_DISKDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2 ; 0x008: TYPE=0x0 NUMB=0x2