Top Issues : Encountered while mounting ASM Diskgroup (文档 ID 2247485.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.1 to 12.1.0.2 [Release 10.2 to 12.1]
Information in this document applies to any platform.

PURPOSE

The purpose of this note is to provide a summary of the top issues that are encountered during mounting of ASM diskgroup

SCOPE

This note applies to Grid Infrastructure for both Clustered and Standalone ASM environment.

DETAILS

Issue #1: ORA-15003 Diskgroup "DATA" Already Mounted in Another Lock Name Space

Symptoms:
ASM diskgroups in single instance environment will not be mounted with the following similar error in sqlplus screen.

SQL> alter diskgroup DATA mount;
alter diskgroup DATA mount
*
ORA-15017 diskgroup DATA cannot be mounted
ORA-15003 diskgroup DATA already mounted in another lock name space

Cause :

1. ASM devices are shared between 2 database servers with single instance ASM environment for migration work.
2. The same diskgroup ( DATA here ) is tried to be mounted on the 2nd node while it is currently mounted on the first node.

Solution :

Refer My Oracle Support Document: 1531734.1

Issue #2: Mounting Diskgroup Fails With ORA-15063 and V$ASM_DISK Shows PROVISIONED

Symptoms:
ASM is restarted and some ASM diskgroups will not be mounted with the following similar error.

SQL> alter diskgroup DATA mount;
alter diskgroup DATA mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup "DATA" cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"

Cause :

Case 1. 0xaa55 on little-endian server like Linux or 0x55aa on big-endain server like Sun Sparc indicates boot signature ( or magic number ) on MBR (Master Boot Record ) Partition.
Case 2. Local backup software ( like Symantec image backup ) touches ASM disk header on column kfdhdb.ub4spare[39] from kfed output.

This issue could happen outside ASM when some tools on OS ( or human ) put partition information on the affected device

Solution :

This situation can happen while the affected diskgroup is mounted and maintenance window needs to be scheduled to repair the device header.

Refer My Oracle Support Document for Action plan: 1487443.1

Issue #3: ORA-01948 When Mounting the ASM Diskgroup

Symptoms:

The ASM diskgroups do not mount when issuing "alter diskgroup all mount" command and failed with the following error:

$ sqlplus '/as sysasm'

SQL*Plus: Release 11.2.0.3.0 Production on Wed Sep 18 16:03:48 2013

Connected to an idle instance.

SQL> startup;
ASM instance started

Total System Global Area 321507328 bytes
Fixed Size 2228024 bytes
Variable Size 294113480 bytes
ASM Cache 25165824 bytes
ORA-01948: identifier's name length (56) exceeds maximum (30)

The ASM diskgroup mount fail information can be observed in oragent log.

/<Node1>/agent/ohasd/oraagent_oragrid/oraagent_oragrid.log:
====================================================================
2013-07-31 14:44:22.358: [ora.asm][1084782912] {0:0:2} [start] InstAgent::startup
2013-07-31 14:44:27.973: [ora.asm][1084782912] {0:0:2} [start] InstConnection::connectInt: server not attached
2013-07-31 14:44:28.061: [ora.asm][1084782912] {0:0:2} [start] AsmAgent::startCbk: {
2013-07-31 14:44:28.061: [ora.asm][1084782912] {0:0:2} [start] AsmAgent::startCbk mount stmt ALTER DISKGROUP ALL MOUNT /* asm agent call crs *//* {0:0:2} */ enable stmt ALTER DISKGROUP ALL ENABLE VOLUME ALL /* asm agent *//* {0:0:2} */
2013-07-31 14:44:28.061: [ora.asm][1084782912] {0:0:2} [start] AsmAgent::startCbk: ALTER DISKGROUP ALL MOUNT /* asm agent call crs *//* {0:0:2} */
2013-07-31 14:44:28.239: [ora.asm][1084782912] {0:0:2} [start] ORA-01948: identifier's name length (56) exceeds maximum (30) <<<<<<<<

2013-07-31 14:44:28.239: [ora.asm][1084782912] {0:0:2} [start] AsmAgent::startCbk: ALTER DISKGROUP ALL MOUNT /* asm agent call crs *//* {0:0:2} */ error 1948
2013-07-31 14:44:28.239: [ora.asm][1084782912] {0:0:2} [start] InstAgent::start: 2 errcode 1948

Cause :

From the ASM parameter file ASM_DISKGROUPS parameter not specified correctly.
asm_diskgroups = "OCR_EDWQA VOTE_EDWQA DATA1_EDWQA DATA2_EDWQA DATA3_EDWQA"

Solution :

Names of the disk groups should be in single quotes. Each of these single quoted names can be up to 30 characters.
asm_diskgroups = 'OCR_EDWQA','VOTE_EDWQA','DATA1_EDWQA','DATA2_EDWQA','DATA3_EDWQA'

Issue #4: ASM Diskgroup Is Running Out Of Space Thus Cannot Be Mounted Due To ORA-15041/ORA-15202

Symptoms:

SQL> alter diskgroup DG_DATA mount;

ORA-15032: not all alterations performed
ORA-15202: cannot create additional ASM internal change segment
ORA-15041: diskgroup "DG_DATA" space exhausted
ERROR: alter diskgroup DG_DATA mount

Cause :

1. This problem occurred due to all the disks members in the diskgroup have close to zero FREE_MB space:
SQL> select TOTAL_MB, FREE_MB, NAME from v$asm_disk;

TOTAL_MB FREE_MB NAME
---------- ---------- ------------------------------
25600 2 DG_DATA_0000
25600 9 DG_DATA_0001
25600 11 DG_DATA_0002
25600 9 DG_DATA_0003

2. One or more disks have V$ASM_DISK.FREE_MB are below the threshold level needed to be able to do a successful rebalance (50-100 MB) to be mounted.

Solution :

1. From any other ASM RAC instance where the diskgroup is still mounted, you will need to release space from the ASM disks members to at least 100MB in the V$ASM_DISK.FREE_MB column by moving some files outside the affected diskgroup.

2. The following document provides an example about who to move files outside diskgroups:
=)> ORA-15041 DURING REBALANCE OR ADD DISK WHEN PLENTY OF SPACE EXISTS (Doc ID 473271.1)

3. After some space was released (about 100MB of FREE_MB in every disk member), you can mount the diskgroup.

4. Then add additional disks to the affected diskgroup:
SQL> alter diskgroup DG_DATA add disk '<disk #1>','<disk #2>',....,'<disk #N>' rebalance power 11;

5. And finally return back the moved files to the affected diskgroup.

Refer My Oracle Support Document: 1592278.1