1/8

Improving ASM Disk Discovery Time

Best Practices.
Overview
ASM_DISKSTRING
The ASM_DISKSTRING initialization parameter specifies a comma-delimited list of
strings that limits the set of disks that an Oracle ASM instance discovers. The discovery
strings can include wildcard characters. Only disks that match one of the strings are
discovered. The same disk cannot be discovered twice.
The discovery string format depends on the Oracle ASM library and the operating
system that are in use. Pattern matching is supported. Refer to your operating systemspecific installation guide for information about the default pattern matching.
For example, on a Linux server that does not use ASMLib, to limit the discovery process
to only include disks that are in the /dev/rdsk/mydisks directory, set the
ASM_DISKSTRING initialization parameter to:
/dev/rdsk/mydisks/*
The asterisk is required. To limit the discovery process to only include disks that have a
name that ends in disk3 or disk4, set ASM_DISKSTRING to:
/dev/rdsk/*disk3, /dev/rdsk/*disk4
The ? character, when used as the first character of a path, expands to the Oracle home
directory. Depending on the operating system, when you use the ? character elsewhere
in the path, it is a wildcard for one character.
The default value of the ASM_DISKSTRING parameter is a NULL string. A NULL value
causes Oracle ASM to search a default path for all disks in the system to which the
Oracle ASM instance has read and write access. The default search path is platformspecific. Refer to your operating system specific installation guide for more information
about the default search path.
Oracle ASM cannot use a disk unless all of the Oracle ASM instances in the cluster can
discover the disk through one of their own discovery strings. The names do not have to
be the same on every node, but all disks must be discoverable by all of the nodes in the
cluster. This may require dynamically changing the initialization parameter to enable
adding new storage.

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

2/8

How A Disk is Discovered

When an Oracle ASM instance is initialized, Oracle ASM discovers and examines the
contents of all of the disks that are in the paths that you designated with values in the
ASM_DISKSTRING initialization parameter.
Disk discovery also occurs when you:
Run the following SQL statements
Mount a disk group with ALTER DISKGROUP ... MOUNT
Online a disk with ALTER DISKGROUP ... ONLINE DISK
Add a disk to a disk group with CREATE or ALTER DISKGROUP...ADD DISK
Resize a disk in a disk group with ALTER DISKGROUP...RESIZE DISK
Query with SELECT ... FROM V$ASM_DISKGROUP or V$ASM_DISK views
Run Oracle Enterprise Manager or Oracle ASM Configuration Assistant (ASMCA)
operations that invoke the SQL statements previously listed
Run ASMCMD commands that perform the same operations as the SQL statements
previously listed
After Oracle ASM successfully discovers a disk, the disk appears in the V$ASM_DISK
view. Disks that belong to a disk group, that is, disks that have a disk group name in the
disk header, show a header status of MEMBER. Disks that were discovered, but that
have not yet been assigned to a disk group, have a status of either CANDIDATE or
PROVISIONED. Disks that previously belonged to a disk group and were dropped
cleanly from the disk group have a status of FORMER.
The PROVISIONED status implies that an additional platform-specific action has been
taken by an administrator to make the disk available for Oracle ASM. For example, on
Windows computers, the administrator might have used asmtool or asmtoolg to stamp
the disk with a header. On Linux computers, the administrator might have used ASMLib
to prepare the disk for Oracle ASM.

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

3/8

Disk Discovery Rules

The rules for discovering Oracle ASM disks are as follows:

Oracle ASM can discover up to 10,000 disks. That is, if more than 10,000 disks
match the ASM_DISKSTRING initialization parameter, then Oracle ASM
discovers only the first 10,000.

Oracle ASM only discovers disk partitions. Oracle ASM does not discover
partitions that include the partition table.

From the perspective of the installation, candidate disks are those that have the
CANDIDATE, PROVISIONED, or FORMER header status. These disks with a
CANDIDATE, PROVISIONED, or FORMER status can be added to Oracle ASM
disk groups without using the FORCE flag.

When adding a disk, the FORCE option must be used if Oracle ASM recognizes
that the disk was managed by Oracle. Such a disk appears in the V$ASM_DISK
view with a status of FOREIGN. In this case, you can only add the disk to a disk
group by using the FORCE keyword.

MEMBER disks can usually be added to a disk group by specifying the FORCE
flag, if the disks are not part of a currently mounted disk group.
In addition, Oracle ASM identifies the following configuration errors during discovery:

Multiple paths to the same disk
In this case, if the disk is part of a disk group, then disk group mount fails. If the disk
is being added to a disk group with the ADD DISK or CREATE DISKGROUP command,
then the command fails. To correct the error, adjust the ASM_DISKSTRING value so
that Oracle ASM does not discover multiple paths to the same disk. Or if you are using
multipathing software, then ensure that you include only the pseudo-device name in the
ASM_DISKSTRING value.

Multiple Oracle ASM disks with the same disk header
This can be caused by having copied one disk onto another. In this case, the disk
group mount operation fails.

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

4/8

Improving Disk Discovery Time

The value for the ASM_DISKSTRING initialization parameter is an operating system
dependent value that Oracle ASM uses to limit the set of paths that the discovery
process uses to search for disks. When a new disk is added to a disk group, each
Oracle ASM instance that has the disk group mounted must be able to discover the new
disk using its ASM_DISKSTRING.
In many cases, the default value (NULL) is sufficient. Using a more restrictive value
might reduce the time required for Oracle ASM to perform discovery, and thus improve
disk group mount time or the time for adding a disk to a disk group. Oracle may
dynamically change the ASM_DISKSTRING before adding a disk so that the new disk is
discovered through this parameter.
The default value of ASM_DISKSTRING might not find all disks in all situations. If your
site is using a third-party vendor ASMLib, then the vendor might have discovery string
conventions that you must use for ASM_DISKSTRING. In addition, if your installation
uses multipathing software, then the software might place pseudo-devices in a path that
is different from the operating system default.
About Discovering Disks
The disk discovery process locates the operating system names for disks that Oracle
ASM can access. Disk discovery finds all of the disks that comprise a disk group to be
mounted. The set of discovered disks also includes disks that could be added to a disk
group.
An Oracle ASM instance requires an ASM_DISKSTRING initialization parameter value
to specify its discovery strings. Only path names that the Oracle ASM instance has
permission to open are discovered. The exact syntax of a discovery string depends on
the platform, ASMLib libraries, and whether Oracle Exadata disks are used. The path
names that an operating system accepts are always usable as discovery strings.

ASM Disk Device Discovery (details)

Once the disks are presented to the OS, ASM needs to discover them. This requires
that the disk devices (Unix filenames) have their ownership changed from root to oracle.
The system administrator usually makes this change. In our example, disks c3t19d5s4,
c3t19d16s4, c3t19d17s4, and c3t19d18s4 are identified, and their ownership set to the
oracle:dba. Now ASM must be configured to discover these disks. This is done by
defining the ASM init.ora parameter ASM_DISKSTRING. In our example, we will use the
following wildcard setting:
*.asm_diskstring='/dev/rdsk/c3t19d*s4'

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

5/8

An alternative to using standard SCSI names (such as cwtxdysz or /dev/sdda) is to use

special files. This option is useful when establishing standard naming conventions and
for easily identifying ASM disks, such as asmdisk1. This option requires creating special
files using the mknod command. For example, to create a special file called asmdisk1
for a preexisting device partition called c3t19d7s4, determine the OS major number and
minor number using the following:
[root@racnode1]# ls -lL c3t19d7s4
crw-r----- 1 root sys 32, 20 Feb 24 07:14 c3t19d7s4
NOTE: Major and minor numbers are associated with the device special files in the /dev
directory and are used by the operating system to determine the actual driver and
device to be accessed by the user-level request for the special device file.
The preceding example shows that the major and minor device numbers for this device
are 32 and 20, respectively. The c at the beginning indicates that this is a character
(raw) file.
After obtaining the major and minor numbers, use the mknod command to create the
character and block special files that will be associated with c3t19d7s4. A special file
called /dev/asmdisk can be created under the /dev directory, as shown:
[root@racnode1]# mkdir /dev/asmdisk
[root@racnode1]# cd /dev/asmdisk
[root@racnode1]# mknod asmdisk1 c 32 20
Listing the special file shows the following:
[root@racnode1]# ls -l
crw-r--r-- 1 root other 32, 20 May 7 07:50 asmdisk1
Notice that this device has the same major and minor numbers as the native device
c3t19d7s4. For this partition (or slice) to be accessible to the ASM instance, change the
permissions on this special file to the appropriate oracle user permissions:
[root@racnode1]# chown oracle:dba disk1
[root@racnode1]# ls l /dev/disk
crw-r--r-- 1 oracle dba 32, 20 May 7 07:50 disk1
Repeat this step for all the required disks that will be discovered by ASM. Now the slice
is accessible by the ASM instance. The ASM_DISKSTRING can be set to
/dev/asmdisk/*. Once discovered, the disk can be used as an ASM disk. ASM discovers
all the required disks that make up the diskgroup using on-disk headers and its search
criteria (ASM_DISKSTRING). ASM scans only for disks that match that ASM search
string. There are two forms of ASM disk discovery: shallow and deep. For shallow
discovery, ASM simply scans the disks that are eligible to be opened.

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

6/8

This is equivalent to executing ls -l on all the disk devices that have the appropriate
permissions. For deep discovery, ASM opens each of those eligible disk devices. In
most cases, ASM discoveries are deep, the exception being when the *_STAT tables
are queried instead of the standard tables.
NOTE: For ASM in clustered environments, it is not necessary to have the same path
name or major or minor device numbers across all nodes. For example, node1 could
access a disk pointed to by path /dev/rdsk/c3t1d4s4, whereas node2 could present
/dev/rdsk/c4t1d4s4 for the same device. Although ASM does not require that the disks
have the same names on every node, it does require that the same disks be visible to
each ASM instance via that instances discovery string. In the event that path names
differ between ASM nodes, the only necessary action is to modify the
ASM_DISKSTRING to match the search path. This is a non-issue on Linux systems that
use ASMLIB, because ASMLIB handles the disk search and scan process.
Upon successful discovery, the V$ASM_DISK view on the ASM instance reflects which
disks were discovered. Note that henceforth all views, unless otherwise stated, are
queried from the ASM instance and not from the RDBMS instance. The following
example shows the disks that were discovered using the defined ASM_DISKSTRING.
Notice that the NAME column is empty and the GROUP_NUMBER is set to 0. This is
because disks that are discovered but are not yet associated with a diskgroup. Thus,
they have a null name and a group number of 0.
SQL> SELECT NAME,PATH,GROUP_NUMBER FROM V$ASM_DISK
NAME PATH GROUP_NUMBER
------------------------------ --------------- -----------/dev/rdsk/c3t19d5s4 0
/dev/rdsk/c3t19d16s4 0
/dev/rdsk/c3t19d17s4 0
/dev/rdsk/c3t19d18s4 0

Disks have various header statuses that reflect their membership state with a diskgroup.
Disks can have the following header statuses:
Former This state declares that the disk was formerly part of a diskgroup.
Candidate A disk in this state is available to be added to a diskgroup.
Member This state indicates that a disk is already part of a diskgroup. Note, that the
diskgroup may or may not be mounted.
Provisioned This state is similar to candidate, in that it is available to be added to
diskgroups. However, the provisioned state indicates that this disk has been configured
or made available using ASMLIB.

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

7/8

The following is a useful query to run to view the status of disks in the ASM
system:
SQL>SELECT
V$ASM_DISK;

NAME,

PATH,

HEADER_STATUS,

MODE_STATUS

FROM

In Oracle ASM 10g R1, querying V$ASM_DISK and V$ASM_DISKGROUP was an

expensive operation because each execution involved a disk discovery. To minimize
overhead, and to allow lightweight access to this dataset, Oracle ASM 10g R2 (and
onwards)
introduced
two
new
views:
V$ASM_DISK_STAT
and
V$ASM_DISKGROUP_STAT. These two views are identical to V$ASM_DISK and
V$ASM_DISKGROUP, but v$ASM_DISK_STAT and V$ASM_DISKGROUP_STAT
views are polled from memory and therefore do not require deep disk discovery.
Because these new views provide efficient lightweight access, Enterprise Manager (EM)
can periodically query performance statistics at the disk level and aggregate space
usage statistics at the diskgroup level without incurring significant overhead.
Steps To Drop a diskgroup and remove the former ASM disks members from the ASM
discovery path:
1) Identify the diskgroup you need to drop:
SQL> select group_number, name from v$asm_diskgroup;
GROUP_NUMBER NAME
------------ -----------------------------1 ACFS
2 ASMNFSDG
3 DATA
4 RECO
5 SPFILEDG
6 TESTDG <(========
6 rows selected.
2) Identify the disk members associated to the diskgroup:
SQL> select path from v$asm_disk where group_number like 6;
PATH
-------------------------------------------------------------------------------/dev/rhdisk12
3) Execute the next statement to drop a diskgroup:
SQL> drop diskgroup TESTDG including contents;

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal

8/8

4) Then if you want to remove the former ASM disks (/dev/rhdisk12) completely from
the ASM discovery path, you can remove the ownership and remove the read and write
permissions associated to those disks as follows:
# chown root:root /dev/rhdisk12
# chmod 000 /dev/rhdisk12
5) Query the v$asm_disk view to make sure the disks was completely removed from the
ASM discovery path:
SQL> select path from v$asm_disk;
7) If you want to partially remove the disks from the ASM discovery string, then you can
modify the ASM_DISKSTRING parameter and removed the desired disks from this
setting, for example:
Original Settings:
ASM_DISKSTRING = '/dev/rhdisk10','/dev/rhdisk11','/dev/rhdisk12','/dev/rhdisk13'
New Settings:
ASM_DISKSTRING = '/dev/rhdisk10','/dev/rhdisk11', '/dev/rhdisk13'

Improving ASM Disk Discovery Time.

Author: Esteban D. Bernal