Professional Documents
Culture Documents
2/8
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.
3/8
4/8
5/8
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.
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
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'