ASM Metadata Dump Utility (AMDU)

Posted by PDSERVICE on Feb 23, 2016 In

If you cannot recover the data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.

Parnassusdata Software Database Recovery Team

Service Hotline: +86 13764045638 E-mail: service@parnassusdata.com

This is a functional description of a utility to quickly

extract all the available metadata from one or more ASM

disks and/or generate formatted printouts of individual

blocks. The dump output can be shipped back to Oracle for

analysis. The utility can be used at Oracle to generate

formatted block printouts from the dump output. The utility

does not require that any disk group is even mountable. It

also has the ability to extract one or more files from an

unmounted diskgroup and write them to the OS file system.

Operations

AMDU performs three different functions. A given execution

of AMDU may perform one, two or all three of these

functions.

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.

The input data may be the contents of the ASM disks, or it

may be derived from a directory created by a previous run

of AMDU. The options -diskstring and -exclude are used to

specify ASM disks to read. The option -directory specifies

a directory created by a previous run of AMDU. The

directory may contain a copy of the original directory

contents. These options are incompatible with each other.

Operational Phases

The basic steps of operation are listed in this section.

Command line options provide the ability to control which

phases are executed and how they operate.

1. Discover disks: This uses ASM discovery to find a set of

disks. The headers are read to determine which disks are

in which diskgroups. The disks to be scanned in the next

phase are chosen. The results of the discovery are put in

the report file. With the option -directory, reading the

existing report file rather than creating a new one

accomplishes this phase.

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. If any files

are being extracted, their extent maps are constructed in

memory from the allocation table entries (extent maps are

ignored). If any blocks are being printed the location of

the blocks is saved in memory. With the -directory option

this phase is accomplished by reading the existing map

files rather than creating map and image files.

3. Extract files: The extent maps of files to extract are

sorted. The file data is read from the ASM disks and

written to output files. If -directory is specified for extraction of

an ASM metadata file, the map and image files are read to build

the extent maps.

4. Printout blocks: Formatted block printouts are written to

standard out along with information about how the block

data was read. A kfed command to dump the block on the

system where the report was generated is also printed.

With the -directory option the data is read from the

image files.

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 so the output files can be easily

tarred and zipped to send back to Oracle. The name of the

directory is based on the time and date to one second

resolution. The directory name is written to standard out

before any files are created in the directory. Note that

the directory name is relative to the current directory

unless a full path name is specified on the command line

with the -parent option.

If AMDU is run with the -directory option then no dump

directory and no output files are created. Instead the -

directory option specifies the location of a previously

created dump directory. In this case -print can be

specified to generate formatted block printouts from the

previously created dump directory. The printouts are sent

to standard out rather than creating a new file. If -extract

is specified with -directory, -output is required to indicate

the location of the extracted file.

Extracted Files

One extracted file is created for every file listed under

the -extract option on the command line. Normally, 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 of the file specified

on the command line. The extracted file will appear to have the

same contents it would have if accessed through the

database. If some portion of the file is unavailable then

that portion of the output file will be filled with

0xBADFDA7A, and a message will appear on stderr.

The -output option can be used to extract a single file to

a specific file name rather than the dump directory. This

can be used in combination with -nodir option to avoid the

creation of a dump directory completely. If -directory is

specified, -output is required.

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). All

the data from one disk will be grouped together in the

image files (possibly spanning a file boundary). Blocks

from a single allocation unit will always be adjacent and

not span image files. 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.

Disks that have been dropped from a disk group will still

contain the group name in their header and may be included

in the image files for that disk group if the -former

option is specified. Note that, unlike mount, the PST is

not consulted to decide which disks are parts of the disk

group. Disks which were forcibly dropped will be included

even without the -former option.

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 <NNNN> is the sequence

number including leading zeroes. The first image file has

sequence number 0001.

<group>_<NNNN>.img

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. The map file contains one line for each

allocation unit that has contents dumped to an image file.

Some allocation units may have an entry in the map file

even though nothing was written to the image file. 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.

The following fields appear in each line. The fields are

separated by blanks. Each field starts with a unique letter

immediately followed by a decimal number with leading

zeroes. This should facilitate using sort and grep to

reorganize the map. In the following descriptions the

leading letter and the number of decimal digits are given

within parentheses. For example (D4) means the letter 'D'

followed by 4 decimal digits.

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

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

3. 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. If there are more than 100 disks

with the same number then extra digits will be printed

and the line sizes will be wrong. This is highly

unlikely.

4. Allocation Unit (A8): The AU within the disk where the

data was read. Note that this is different than the

extent number for physically addressed metadata since

extent 2 is near AU 113,000. If the disk is greater than

100 terabytes and the AU size is one megabyte, then this

field could exceed 8 digits.

5. 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. If this is physically addressed metadata

then the file number will be 00000000.

6. Indirect flag (I1): If this is a data extent for the file

then the indirect flag is 0. If this is an indirect

extent then this is 1.

7. Extent Number (E8): The physical extent number within the

file. This is the index in the file extent map that a

database instance would use to find this AU. If the file

was (two-way) mirrored then this is a primary extent if

the number is even, and a secondary copy if it is odd. If

this is an indirect extent then this is a value between 0

and 299 giving the index into the indirect extents. For

physically addressed metadata this is the extent within

the physically addressed metadata, not the AU within the

disk.

8. AU within extent (U2): Large extents are supported for

large files. Thus there could be multiple AU's dumped for

the same extent. Note that metadata files do not

currently use large extents so this only happens for user

file dumps to image files.

9. Block count (C5): The number of blocks copied to the

image file from the AU. A lot of space is saved by not

creating images of blocks that are just initialized

contents. This is particularly true for indirect extents

where most indirect extents will have only a few blocks

of extent pointers. If the extent is not dumped to the

image file then this is zero. The count is in ASM

metadata blocks, even if the file number is >256 and the

indirect flag is 0. This is normally 4K blocks, but could

be different in the future. With the -noimage option this

is always zero since no images are ever created.

10. Image File Sequence Number (S4): This is the NNNN

field of the image file name where blocks from the AU are

dumped. With the -noimage option this is always zero

since no image files are ever created.

11. Byte Offset in Image File (B10): This is the location

within the image file where the block images appear. It

is always a multiple of the ASM metadata block size.

Since the image file is always less than 2Gb this will

always fit in a 32 bit signed integer. Note that this

will be an offset to the end of the previously dumped AU

when the block count is zero. With the -noimage option

this is always zero since no images are ever created.

12. Corrupt Block Flag (X0): If any of the blocks in the

AU are corrupt, then the line will end with 'X'. Normally

this is a blank character so that the line ends in two

blanks.

This adds up to 56 digits, 12 letters, 11 blanks, and one

'\n' per line. This is a total of 79 characters including

the newline.

The map files are named "<group>.map" where <group> is the

disk group name in uppercase.

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. The title line has the

title centered and surrounded with '*'. There are always at

least three asterisks on either side of the title. A

subsection title is like a section title except that it is

surrounded with '-' rather than '*'.

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.

The CORE package LRM is used to parse the command line

arguments. No dump directory or report file is generated if

there are argument parsing errors or if the user is only

requesting help. Command line errors will result in an exit

status of 1 rather than 0. Problems reading disks or

extracting a file will be reported on stderr and the report

file. The exit status will be 5 in accordance with LPM

standards.

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.

If the -noscan option is specified then this is the end of

the report. If the -noread option is given then this is the

end of the report and there is no deep discovery

information for any of the disks.

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.

Diskgroup Scan

There is one section for every disk group encountered by

deep discovery and referenced in either a -dump, -extract

or -print option ("-dump all" references all diskgroups

mentioned in any valid disk headers). The name of the disk

group is in the section header. This is followed by

information gathered about the diskgroup during deep. 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.

A group report subsection follows all the disk scan

subsections for the disks in the group. This subsection

gives cumulative statistics from all the disks in the disk

group.

Extracting File Sections

A section is reported for each file that is extracted. The

section header includes the diskgroup name and file number

from the -extract option. The name of the OS file created

by the extraction is on the first line of the section. Any

errors encountered are reported followed by statistics

about the extraction. If -directory is indicated, this info

will be writted to stdout.

End of Report

The last line of a report is the end of report section

header.

Printing Blocks

The -print option can be used to generate a formatted

printout of blocks from a diskgroup that is scanned in this

run of AMDU or from a dump directory created by a previous

run of AMDU. Use the -directory option to print from a

previous AMDU run.

Output Format

The formatted output is sent to standard out rather than to

a file. A section header, as in a report file, is printed

for each -print option on the command line. The section

header includes the block specification for the printout.

There is one subsection for each count in the block

specification. The subsection title is "BLOCK n OF c" where

n is the number of this block (starting at one), and c the

count of blocks in the block specification.

There may be multiple blocks on disk that match the

criteria for printing in one subsection. This may be due to

multiple disks appearing to be the same ASM disk or it may

be due to the normal mirroring of data. With the -fullscan

option it is common to encounter old stale blocks that

match the same criteria. A block description is printed for

each block that matches the printing criteria. When the

block contents are identical, then multiple block

descriptions are printed before the formatted printout of

the block. If the blocks are different then there may be

multiple formatted printouts in one subsection.

A block description consists of three lines. The first line

is a separator of all dots. The second line gives the

location of the block both as (disk, AU, block) and (file,

extent, block). The third line is the kfed command that

would create the same formatted output. This is useful for

constructing a kfed command to patch the block. It includes

the device name of the disk on the system where the dump

was created. If the AMDU directory was copied from another

system then the kfed command will have to be run on the

other system.

Block Specification

There are five different kinds of <block_spec>'s for

specifying a range of blocks to printout. They all start

with a diskgroup name. The name is case insensitive but it

is converted to uppercase. The name is followed by values

specified by '.', letter, number. The letter indicates the

meaning of the number and may be upper or lower case. The

number is a decimal number less than 2^32. The last value

may be an optional count of blocks to print using the

letter 'C'. So if the last field is ".C4" Then four blocks

will be printed starting at the first one specified by the

<block_spec>.

The five forms are as follows:

1. Report disk block: This form specifies a disk by it's

discovery order and a block by AU and block within AU.

The disk report number is always unique, but it is hard

to know the number unless you have already run AMDU and

seen at least the shallow discovery report. The advantage

of this form is that it never refers to multiple blocks

since AMDU gives every disk a unique disk report number.

For example <block_spec> "DATA.N0001.A1.b0.c256" would

dump the entire PST AU from the first disk discovered

(providing it is in disk group DATA). Note that the

diskgroup name must match even though disk report numbers

are unique.

2. Group disk block: This is similar to report disk block

except that the ASM disk number is given rather than the

report disk number generated by AMDU. It is possible, but

a bad configuration, to see more than one disk with the

same ASM disk number for the same ASM disk group. If this

happens then this <block_spec> will refer to the blocks

on all the disks.

For example <block_spec> "Data.d2.A0.B0" would print the

disk header from disk 2 in diskgroup DATA. Also

<block_spec> "data.d2.a0.b256" and "data.d2.a1.b0" would

both print the PST header block of disk 2 in diskgroup

DATA (assuming an AU size of 1 MB and metadata block size

of 4096).

3. Extent file block: This form allows specification of a

block by a file physical extent number and block within

extent. When a file is mirrored there are two physical

extents for every virtual extents. This form allows

specification of only one mirror copy. It will support

printing of any file that is described by the map file.

However it is unlikely that a block dump will produce

anything but hex data for anything that is not an ASM

metadata file. Note that the block size is always the ASM

metadata block size no matter which file is being

printed. Note that any striping is not taken into account

when locating the block.

For example <block_spec> "flash.F3.X42.B0" would print

the secondary mirror copy of the checkpoint block of ACD

thread 2 in diskgroup FLASH. "Data.f3.x0.b0.c10752" would

print all the redo for thread 1 in diskgroup DATA (I hope

you have an empty file system)

4. Virtual file block: This form allows specification of a

block by its virtual block number within the file. Unless

this is an external redundancy disk group, all 3 copies

of the block are printed. If the copies are the same then

only one printout of the contents is generated. This form

is only allowed for ASM metadata files because the

redundancy can be determined from the diskgroup type, and

there is no striping.

For example <block_spec> "flash.F1.v2856" would print the

file directory block for file 2856 in diskgroup FLASH.

5. Extent map file block: This form allows specification of

a block in a files extent map. The first 60 extent

pointers are in the file directory the rest are in extent

map with 480 pointers per map block. For example

<block_spec> "flash.f2856.m0.c427" would print the entire

extent map for a 200GB file number 2856.

Command Line

AMDU uses the LRM package from CORE to parse its command

line. Thus it follows the LRM conventions. In particular it

follows the unix command style. The command line looks like

this:

admu [ <option> ... ]

Some options require specification of a number or string

while others are boolean flags that do not require a value.

Some options may appear multiple times to provide multiple

values. String options are specified as follows:

-keyword string

Number options are specified as:

-keyword number

Note that a number may end in K, k, M, m, G, or g to

indicate kilo (2^10), mega(2^20), or giga (2^30).

Boolean flags are specified as:

-keyword

Note that the CORE package LRM is used to parse the command

line options. This means you can specify options as

keyword=value, but unless you are very clever and

understand completely how LRM works, you will get

unexpected results such as ignored parameters. Stick to -

keyword syntax and you will be fine.

The options fall into four broad classes: operations, disk

selection, read control, and output control.

Operation

These parameters control the fundamental function of AMDU:

dumping metadata, extracting file contents, or printing

metadata blocks. If none of these are specified then only

discovery is performed (same as -noscan).

1. -dump <diskgroup>: This option specifies the name of a

diskgroup to have its metadata dumped. This option may be

specified multiple times to dump multiple diskgroups. If

the diskgroup name is "ALL" then all diskgroups

encountered will be dumped. The diskgroup name is not

case sensitive, but will be converted to uppercase for

all reports. If this option is not specified then no map

or image files will be created, but -extract and -print

may still work.

2. -extract <diskgroup>.<file>: This extracts the file (by name

or number) from the named diskgroup, case insensitive. This

option may be specified multiple times to extract

multiple files. The extracted file is placed in the dump

directory under the name <diskgroup>_<number>.f where

<diskgroup> is the diskgroup name in uppercase, and

<number> is the file number. The -output option may be

used to write the file to any location and is required

if -directory is specified. The extracted

file will appear to have the same contents it would have

if accessed through the database. If some portion of the

file is unavailable then that portion of the output file

will be filled with 0xBADFDA7A, and a message will appear

on stderr.

ASM metadata files Number Name

FILE DIRECTORY 1 FILE

ASM DISK DIRECTORY 2 ASMDISK

ACTIVE CHANGE DIRECTORY 3 CHANGE

CONTINUING OPERATIONS DIRECTORY 4 CONTOP

TEMPLATE DIRECTORY 5 TEMPLATE

ALIAS DIRECTORY 6 ALIAS

AVD VOLUME FILE DIRECTORY 7 VOL

USED SPACE 8 USEDSPC

ATTRIBUTES DIRECTORY 9 ATTRIBUTES

ASM USER DIRECTORY 10 USER

ASM USER GROUP DIRECTORY 11 GROUP

STALENESS DIRECTORY 12 STALENESS

Files which have fixed numbers but are not ASM metadata files

STALE BITMAP SPACE REGISTRY 254 STALEREG

ORACLE CLUSTER REPOSITORY REGISTRY 255 OCR

3. -print <block_spec>: This option prints one or more

blocks to standard out. This option may be specified

multiple times to print multiple <block_spec>'s. The

printout contains information about how each block was

found as well as a formatted printout. Multiple blocks

matching the same <block_spec> may be found when scanning

the disks. For example there may be multiple disks that

have headers for the same diskgroup and disk number. If

the block is from a mirrored file then multiple copies

should exist on different disks. If multiple copies of

the same block have identical contents then only one

formatted printout of the contents will be generated, but

a header will be printed for each copy. A <block_spec>

may include a count of sequential blocks to print. A

<block_spec> may specify a block either by disk or file.

<block_spec> ::= <single_block> | <single_block>.C<count>

<single_block> ::= <report_disk_block> | <group_disk_block> |

<extent_file_block> | <virtual_file_block> | <xmap_file_block>

<report_disk_block> ::=

<group_name>.N<report_number>.A<au_number>.B<block_number>

<group_disk_block> ::=

<group_name>.D<disk_number>.A<au_number>.B<block_number>

<extent_file_block> ::=

<group_name>.F<file_number>.X<physical_extent>.B<block_number>

<virtual_file_block> ::=

<group_name>.F<file_number>.V<virtual_block_number>

<xmap_file_block> ::=

<group_name>.F<file_number>.M<extent_map_block_number>

Disk Selection

These parameters control the disk discover phase of

operations. They allow specification of which disks should

be scanned for AU's to dump. The operation options -dump, -

extract, and -print also limit scanning to disks in the

diskgroups specified by the options. The following options

can be specified to control how the disks are discovered

and scanned

1. -diskstring <string>: By default the null string is used

for discovery. The null string should discover all disks

the user has access to. Many installations specify an

asm_diskstring parameter for their ASM instance. If so

that parameter value should be given here. Multiple

discovery strings can be specified by multiple

occurrences of -diskstring <string>. Beware of shell

syntax conflicts with discovery strings. Diskstrings are

usually the same syntax the shell uses for expanding path

names on command lines so they will most likely need to

be enclosed in single quotes.

2. -exclude <string>: Multiple exclude options may be

specified. These strings are used for discovery just like

the values for diskstring. Only shallow discovery is done

on these diskstrings. Any disks found in the exclude

discovery will not be accessed. If they are also

discovered using the -diskstring strings, then the report

will include the information from shallow discovery along

with a message indicating the disk was excluded.

3. -former: Normally disks marked as former are not scanned,

but this option will scan them and include their contents

in the output. This is useful when it is necessary to

look at the contents of a disk that was dropped. Note

that dropped normal disks will not have any entries in

their allocation tables and thus only the physically

addressed extents will be dumped. Force dropped disks

will not have status former in their disk headers and are

not affected by this option. However if DROP DISKGROUP is

used, the disks will have the contents as of the time of

the drop, and will be in status former. Thus this option

is useful for extracting files from a dropped diskgroup.

4. -baddisks <diskgroup>: Normally disks with bad disk

headers, or that look like they were never part of a disk

group, will not be scanned. This option forces them to be

scanned anyway and to be considered part of the given

diskgroup. This is most useful when a disk header has

been damaged. The disk will still need to have a valid

allocation table to drive the scan unless -fullscan is

used. If block 0 is damaged, AMDU will try to read the

backup disk header. If this fails, and AMDU needs to

construct a working disk header, at least one block in the

first two AUs must be valid so that the disk number can be

determined. The options -ausize and -blksize are required

since these values are normally fetched from the disk header.

If the diskgroup uses external redundancy then -external should

be specified. These values will be compared against any

valid disks found in the diskgroup and they must be the

same.

5. -directory <string>: This option completely eliminates

the discovery and disk scanning phases of operation. It

specifies the name of a dump directory from a previous

run of AMDU. The report file and map files are read

instead of doing a discovery and scan. The parsing of

these ASCII files is very dependent on them being exactly

as written by AMDU. AMDU is unlikely to work properly if

they have been modified by a text editor, or if some of

the files are missing or truncated. Note that the

directory may be a copy FTP'ed from another machine. The

other machine may even be a different platform with a

different endianess.

Read Control

These parameters control which AU's on a disk are read and

how they are found. Every AU read from a -dump diskgroup is

dumped, unless the -noimage output option is set. Reading

still checks for I/O errors and corrupt blocks even if -

noimage is set. The default scanning algorithm is to look

at the allocation table and dump any extent that contains

ASM metadata according to its allocation table entry. The

registries are not considered metadata and are not dumped

by default. Registries are not modified through the ASM

buffer cache, and may not have ASM block headers on them.

If part of the AU contains metadata blocks that were never

modified, then the unmodified blocks are not dumped. The

most common case is the extra blocks in an indirect extent.

1. -fullscan: This option reads every AU on the disk and

looks at the contents of the AU rather than limiting the

AU's read based on the allocation table. This is useful

when the allocation table is corrupt or needs recovery.

An AU will be written to the image file if it starts with

a block that contains a valid ASM block header. The file

and extent information for the map will be extracted from

the block header. Physically addressed metadata will be

dumped regardless of its contents. This option is

incompatible with extracting a file. It is an error to

specify -extract with this option. Note that this option

is likely to find old garbage metadata in unallocated

AU's since there is no means of determining what is

allocated. Thus there may be many different copies of the

same block, possibly of different versions.

2. -ausize <bytes> -blksize <bytes>: Both of these options

must be set when -baddisks is set. They must both be a

power of 2. These sizes are required to scan a disk

looking for metadata, and it is normally read from the

disk header. The values apply to all disks that do not

have a valid header. The values from the disk header will

be used if a valid header is found.

3. -external: Normally amdu determines the diskgroup

redundancy from the disk headers. However this is not

possible with the -baddisks option. It is assumed that

the redundancy of diskgroup "none" is normal or high

unless this option is given to specify external

redundancy.

4. -compare: This option only applies to file extraction

from a normal or high redundancy disk group. Every extent

that is mirrored on more than one discovered disk will

have all sides of its mirror compared. If they are not

identical a message will be reported on standard error

and the report file. The message will indicate which copy

was extracted. A count of the blocks that are not

identical will be in the report file.

5. -registry: The ASM registries will be read and dumped to

the image file. There will be no block consistency checks

since these files do not have ASM cache headers. To dump

one specific registry specify -filedump and include the

file object for the registry (e.g. DATA.255)

6. -noheart: Normally the heartbeat block will be saved at

discovery time and checked when the disk is scanned. A

sleep is added between discovery and scanning to ensure

there is time for the heartbeat to be written. If the

heartbeat block changes then it is most likely that the

diskgroup containing this disk is mounted by an active

ASM instance. An error and warning is generated but

operation proceeds normally. This option suppresses this

check and avoids the sleep.

7. -noxmap: This option eliminates reading of the indirect

extents containing the file extent maps. This is the bulk

of the metadata in most diskgroups. Even the entries in

the map file will be eliminated.

8. -novirtual: This option eliminates reading of any virtual

metadata. Only the physically addressed metadata will be

read. This implicitly eliminates the ACD and extent maps

so -noacd and -noxmap will be assumed.

9. -noscan: This eliminates any reading of any disks after

deep discovery. This results in just doing a deep

discovery using the disksting parameter. The report will

end after the discovery section. It is an error to

specify this option and specify a file to extract. It is

an error to specify this and -fullscan.

10. -noread: This eliminates any reading of any disks at

all. Only shallow discovery will be done. The report will

end after the discovery section. It is an error to

specify this option and specify a file to extract or

blocks to print. It is an error to specify this and -

fullscan.

Output control

Output control parameters change which output files are

created, where they are created, and how they are created.

The following options are supported.

1. -parent <path_name>: By default the dump directory is

created in the current directory, but another directory

can be specified using this option. The parent directory

for the dump directory must already exist.

2. -noacd: This option limits the dumping of the Active

Change Directory to just the control blocks that contain

the checkpoint. There is 126 MB of ACD per ASM instance

(42 MB for external redundancy). It is normally of no

interest if there has been a clean shutdown or no updates

for a while. This option avoids dumping a lot of

unimportant data. The blocks will still be read and

checked for corruption. The map file will still contain

entries for the ACD extents, but the block counts will be

zero.

3. -noimage: No image files will be created n the dump

directory. All the reads specified by the read options

will still be done. The map files may be used to find

blocks on the disks themselves. In the map file, the

count of blocks dumped, the image file sequence number,

and the byte offset in the image file will all always be

zero (C00000 S0000 B0000000000).

4. -nomap: No map file is created and no image file is

created. The only output is the report file. The -noimage

option is assumed if this is set since an image file

without a map is useless. The options -noscan and -noread

also result in no map or image files, but -nomap still

reads the metadata to check for I/O errors and corrupt

blocks.

5. -filedump: This option causes the file objects in the

command line to have their blocks dumped to the image

files rather than extracted. This can be combined with

the -novirtual option to selectively dump only some of

the metadata files. It may also be used to dump user

files (number >= 256) so that all mirrored copies can be

examined.

6. -output <file_name>: This option specifies a different

file for writing an extracted file. The file will be

overwritten if it already exists. This option requires

that exactly one file is extracted via the -extract

option. Required with -extract and -directory.

7. -noextract: This prevents files from being extracted to

an output file, but the file will be read and any errors

in selecting the correct output will be reported. This is

most useful in combination with the -compare option.

8. -nodir: No dump directory is created, and no files are

created in it. The directory name is not written to

standard out. The report file is written to standard out

before any block printouts from any -print options. This

option conflicts with -filedump. It is an error to

specify this and extract a file to the dump directory.

9. -noreport: This suppresses the generation of the report

file. It is most useful in combination with -nodir and -

print to get block printouts without a lot of clutter. It

is unnecessary to include this with -directory since no

report is generated then anyway.

10. -hex: This prints the block contents in hex without

attempting to print them as ASM metadata. This is useful

when the block is known to not be ASM metadata. It avoids

the ASM block header dump and ensures the block is not

accidentally interpreted as ASM metadata. This option

requires at least one -print option.

11. -noprint: This suppresses the printout of the block

contents for blocks printed with the -print option. It is

useful for getting just the block reports without a lot

of data. This option requires at least one -print option.

Inconsistencies

Since AMDU does not do all the checks required to mount a

diskgroup, it is possible for the disks to be inconsistent.

There may be missing disks or older stale disks. There

could be two different diskgroups with the same name. Since

the diskgroup may need crash recovery there could be

duplicate entries for the same file extent in the

allocation tables. Here are a list of the possible

inconsistencies and how they are dealt with

1. There could be two paths to the same disk. If two disks

have identical headers it is assumed they are the same

disk. The second disk is ignored and a message appears in

place of its deep discovery report.

2. There could be disks from two different diskgroups with

the same diskgroup name. An error message is given and

the disk group is not scanned. No files will be extracted

from the diskgroup and no metadata will be dumped or

printed. Use the exclude parameter to eliminate the disks

from one disk group.

3. There could be two disks in the same diskgroup with the

same disk number. This happens if a disk is dropped

force, another disk is added, and the old disk is

discovered by AMDU. Metadata will be dumped for both

disks. A file extraction will only look for extents on

the disk with the highest disk creation timestamp. The

other disk will be ignored even if it contains the only

copy of an extent.

4. There could be two AU's that are for the same file and

extent. This can happen if a relocation is incomplete.

For metadata dumping both extents are dumped. For file

extraction the contents will be compared. If they are the

same then there is no problem. If the contents differ

then the disk with the lowest disk report number will be

chosen. An error message will indicate the problem and

which disk was chosen.

5. With the -compare option the mirror copies of an extent

could differ. If this happens the primary extent will be

chosen. With high redundancy and a missing primary extent

the first secondary will be chosen. An error message will

be reported.

You are here

ASM Metadata Dump Utility (AMDU)