In this Document
Purpose |
Requirements |
Configuring |
KNOWN ISSUES |
Instructions |
Script |
Sample Output |
References |
On Oracle 10g the content of a diskgroup can be reviewed if the diskgroup is mounted and there are internal views that display the specific allocation of the files (ASM files and Database files) inside of the disks.
When the diskgroup is not mounted, this information is not available, which makes difficult to diagnose the errors avoiding the diskgroup to be mounted. This problem has been resolved with AMDU.
AMDU is a tool introduced in 11g where it is posible to extract all the available metadata from one or more ASM disks, generate formatted block printouts from the dump output, extract one or more files from a diskgroup (mounted/unmounted) and write them to the OS file system.
This tool is very important when dealing with internal errors related to the ASM metadata.
Although this tool was released with 11g, it can be used with ASM 10g.
This document provides the links to download the files required to run AMDU with an ASM 10g environment.
Platform | |
---|---|
Linux X86 (Platform 46) | amdu_lnx_32.zip |
Linux X86-64 AMD64/EM64T (Platform 226) | amdu_lnx_X86-64.zip |
Solaris 10 Sparc 64bit (Platform 23) | amdu_solaris10_64.zip |
Solaris 9 Sparc 64bit (Platform 23) | amdu_solaris9_64.zip |
HP-UX PA-RISC 64bits (Platform 59) | amdu_HP-PARISC.zip |
HP-UX Itanium (Platform 197) | amdu_hp_itanium.zip |
AIX | amdu_aix.zip |
* Additional platforms will be added
The scope of this document is not to explain AMDU usability and characteristics. The main goal is to provide a placeholder where AMDU can be downloaded and use on Oracle 10g environments. For Oracle 11g, this tool is part of the distribution and will be present on the $ORACLE_HOME/bin directory.
For specific details, please check the step-by-step section.
NOTE: If a core dump or any error is reported during the execution, please submit a remark, so the binary can be replaced.
1. Download the zip file referenced in Table 1 and transfer to the server.
2. Unzip the content
3. If using different ORACLE_HOMEs for ASM and DB, use the ASM location. Modify variable LD_LIBRARY_PATH or LIBPATH (on AIX) or equivalent, to include the directory where amdu was downloaded. Also modify PATH variable:
* Execution of amdu could failed with a core dump.
Reviewing the callstack in the coredump:
#0 0x0806235d in slfipn ()
#1 0x0805e88c in lfimknam ()
#2 0x081123bd in kfmuCreateDirectory ()
#3 0x0810a753 in kfmu_main ()
#4 0x08091a13 in lpmcall ()
#5 0x08065678 in lpmpmai ()
#6 0x08057fb9 in main ()
This is due to bug 5997071. The workaround is to unset any NLS* variable, starting with NLS_LANG.
There are two main parameters:
-diskstring Identify the location where the devices used by diskgroup are located.
-dump Define the diskgroup whose content will be dumped by AMDU
Below is an example of how to use amdu, particularly to find the location of the DISK DIRECTORY.
In the map file (*.map) we look for F00000002: (Disk Directory is always asm file# 2)
Now, read report.txt to identify the disk using N0014 and D0002:
The AMDU information indicates that Disk Directory is located at AU 2 from Disk# 2 identified with path /dev/asmdisk17.
Use kfed to get that specific AU:
$ kfed read /dev/asmdisk17 aunum=2 blknum=0 text=disk17_dd.txt
Note: Start reviewing from block 0. The entry of the added disk may be in a different block.
None
Every time AMDU is executed a directory is created on the current location, unless it is override by parameter -directory. The directory will have the format amdu_YYYY_MM_DD_HH24_MM_SS
The default command referenced in the step-by-step section, will generate following files:
Here are some details about the files:
1. report.txt
Like the name, it include details about the disks scanned (name, diskgroup name, failgroup name, size, creation time, etc).
2. *.map
For every diskgroup referenced on command -dump, will be a *.map file, which can be used to find the exact location of the ASM metadata on the disks. This file is a key component when reviewing specific areas of the metadata.
3. *.img
For each diskgroup, could be many image files. The size is limited to 2gb and will be a exact dump of the content of the diskgroup.
Compress all the files under the directory and ask the customer to upload them to the Service Request.