In this Document
  Purpose
  Scope
  Files for Upload When Creating ASM/Storage Service Requests
  References

Purpose

Scope

Files for Upload When Creating ASM/Storage Service Requests

Required Data Collection for ASM Storage issues.

When opening a service request to the storage support group the following information needs to be uploaded at service request creation time to speed analysis and resolution of your issue. All of the information documented below in the generic section is required for all service requests opened to ASM/storage support group. In addition to the generic information, additional information for specific types of issues is also being listed by type of problem. The more of this information that you provide initially the less time it will take to progress and resolve the issue.

GENERIC

The full alert.log for all ASM instances in the environment must be uploaded at service request creation time. For 10.1 and 10.2 this file is will be located in the bdump directory for the home where you are running ASM. Full log mean from the last successful startup and mount of the diskgroups to present.

For 11.1 there are 2 versions of the alert.log one in XML format the other in text format. We need the text format version of the alert.log. This file should be located in the $ORACLE_BASE/trace directory and will end with .log extension.  Directory structure should be something similar to the following:  $ORACLE_BASE/diag/asm/+asm/+ASM/trace

For 11.2 there are also 2 versions of the alert.log one in XML and one in text format. We still need the text format version of the alert.log. In this case the file will be located in the diagnostic destination trace directory for the Grid Infrastructure home.

If this is a RAC configuration we must have these logs from all instances in the cluster regardless of them being up or not.

For all ASM issues we will need the output of the following script. This script is run against the ASM instance.

For 10G versions of ASM please set the ORACLE_HOME to point to the software installation that is used to start the ASM instance. Please set the ORACLE_SID to point to an ASM instance. In case of single instance installation it will be set to +ASM. In case of RAC installation the +ASM will be appended by an instance number. We will require this output from all ASM instances for the environment we are addressing the problem on. Start the sqlplus session(s) and connect / as sysdba.

For 11.1 configuration the same script will be run and the ORACLE_HOME will be set the same as it is for 10G versions listed above. The ORACLE_SID will also be set the same way. When starting the sqlplus session(s) you can connect / as sysdba or / as sysasm user.

For 11.2 installation please set the ORACLE_HOME to point to the Grid Infrastructure home and set the ORACLE_SID to point to an ASM instance. The same applies for all versions regarding the setting of the ORACLE_SID. Start sqlplus session and connect / as sysasm user. Run the script listed below against all ASM instances regardless of version

For all versions above if running the below script against RAC configuration please change in the first line of the script to indicate the instance number you are connected to at the time of execution and repeat for all instances numbers in the configuration. If this is not a RAC configuration please remove from the first line of the script before execution.


First script located in the next note:

=)> How To Gather/Backup ASM Metadata In A Formatted Manner? Document  470211.1



ASM Space Issues

In addition to the generic information in the fist section for space issues such as ORA-15041 errors please also collect the following and upload at the time of service request execution.

Please review Information to gather when diagnosing ASM space issues (Doc ID 351117.1). Collect the output of the asmdebug.sql output from all ASM instances.

Please upload the parameter file used to start the ASM instances.



ASM corruption issues

For ASM corruption issues please collect the following additional information to include with the generic information collected from the first section of the note.

1. We will need kfed output of the header of all disks that are part of the affected diskgroup in Unix environments..

Building and using the kfed utility
------------------------------------

* For releases 10.2.0.X and up execute:
1) Change to the rdbms/lib directory:

% cd $ORACLE_HOME/rdbms/lib

2) Generate the executable:

10.2.0.XX:

% make -f ins_rdbms.mk ikfed
3) Verify kfed was copied to $ORACLE_HOME/bin

% ls -l $ORACLE_HOME/bin/kfed

Using kfed:

Reading a file:

kfed read

example:

% kfed read /dev/raw/raw1

Please substitute your disk path and device names for the ones provided above in the example. Please redirect the output of all of the reads to append to a text file to be uploaded for our review.

2. In Unix environments please execute the following command for each device that is suppose to be part of the affected diskgroup. This will take a binary copy of the first 50 MB of each disk that is part of the diskgroup. This can be beneficial in root cause analysis.

dd if= of= bs=1048576 count=50

3. Please review the following documents. Please collect the AMDU output for the affected diskgroup. This is critical to determine the extent of the corruption in the diskgroup.

Placeholder for AMDU binaries and using with ASM 10g (Doc ID 553639.1)

4. Please also upload the OS logs covering a period of at least 1 day prior to the first occurrence of the problem. OS logs require root access on Unix boxes and require administrator access on Windows platforms. If this is a RAC configuration we will need these logs from all servers in the cluster.

OS logs can be found in the following locations described in the next note:

=)> How To Gather The OS Logs For Each Specific OS Platform. Document 1349613.1


All issues in RAC configurations

For all issues opened to storage for RAC configuration from 10.2 to current the following information from all nodes in the cluster will be extremely helpful

Please review CRS 10gR2/ 11gR1/ 11gR2 Diagnostic Collection Guide (Doc ID 330358.1). Do not collect the RDA output but do collect the diagcollection script output. On Unix platforms this script needs to be executed as the root user. It will produce several zip files for each node in the cluster. Please zip those into a single zip file per server and upload to the service request for our review.

Additional needed information for Linux Platforms if ASMLib is being used.

If you are on a Linux platform and are using ASMLib the following additional information would be quite helpful in progressing your issue if it is related to disk discover or ASMLib errors in the alert.log as described in the next note:

=)> Collecting The Required Information For Support To Troubleshot ASM/ASMLIB Issues. Document 869526.1

References