ASM disk groups are the foundation of ASM. It is where your data will be stored. ASM disk groups can be allocated to raw disk, cooked disk. To add a ASM disk group you first need to set the ASM_DISKSTRING parameter. You can then add disk groups to your ASM instance.

Setting the ASM_DISKSTRING Parameter

The parameter file for the ASM instance should contain a parameter called ASM_DISKSTRING (see Creating the ASM Instance). This parameter contains the paths that Oracle will use to try to find the various candidate disks available for ASM's use. The process of ASM finding disks in the ASM_DISKSTRING path is known as discovery.

You may not need to set ASM_DISKSTRING. ASM_DISKSTRING has a number of different default values depending on the platform you are using. Here is a table that contains the list of platform specific default values (these will be set if ASM_DISKSTRING is set to a NULL value only):

Platform NameDefault ASM_DISKSTRING value
AIX /dev/rhdisk*
HP-UX /dev/rdsk/*
Linux /dev/raw/*
Mac OS X /dev/rdisk*s*s1
Solaris /dev/rdsk/*
Tru64UNIX /dev/rdisk/*

You can have multiple locations in the ASM_DISKSTRING parameter (we will provide an example of this in just a moment). If you insert a ? placeholder at the beginning of the string, Oracle will expand that out to represent the location of the parameter values. The ASM_DISKSTRING can be dynamically altered, which is nice if your friendly system administrator adds a some storage to your system that you want Oracle to be able to use. If you happen to change ASM_DISKSTRING dynamically and the new disk path is not present it will revert to the old disk path. Removing an existing disk path, when that disk path is in use, will result in a failure of the command.

Another thing to consider when determining how to configure the ASM_DISKSTRING parameter is performance. Leaving this parameter set to NULL, and thus taking the Oracle default, will often be sufficient. However, if you set ASM_DISKSTRING, using a more restrictive set of parameters, you may find that discovery of disks will be faster. For example, using the default Linux setting of /dev/raw/* will result in ASM scanning the entire /dev/raw file system structure (it does not search sub folers). If you have a large number of devices in this structure, this may take some time. If however your disk devices in this structure are all prefixed with the work raw (raw1, raw2, raw3, etc) then setting the ASM_DISKSTRING to '/dev/raw/raw*' could reduce the time it take ASM to perform discovery and improve performance of the startup of the ASM instance.

Something that is common to all ASM_DISKSTRING parameters is the use of the asterisk. The asterisk is required when defining the ASM_DISKSTRING parameter. Here are some examples of setting the ASM_DISKSTRING parameter.

In this example, we will point ASM to look for disks in devices when we create disk groups:

Alter system set ASM_DISKSTRING='/devices/*';

In this example, we are pointing ASM_DISKSTRING to ORACLE_HOME/disks:

Alter system set ASM_DISKSTRING='?/disks/*';

In this example we are pointing ASM_DISKSTRING to two different locations:

Alter system set ASM_DISKSTRING='?/disks/d1/*,?/disks/d21/*';

We could also use some adjunctive regular expressionish type extensions, and perform the allocation this way:

Alter system set ASM_DISKSTRING='?/disks/d[12]/*';

ASM Disk Group Attributes

In Oracle 10g and earlier you had to use templates to assign attributes to ASM disk groups. Oracle 11g introduced the new ASM attribute clause. The attribute clause allows you to assign attributes directly to ASM disk groups without having to use templates. Oracle 11g adds new attributes that you can assign via a template or using the attribute clause. Both the CREATE DISKGROUP and the ALTER DISKGROUP commands allow you to define or modify these settings as required. The following table shows a list of the attributes you can set with the new attribute clause.

au size This attribute defines the allocation unit size. This parameter defaults to 1MB. The au attribute can only be set when the disk group is created. The value of AU can be any power of 2 (1,2,4, 8, etc..) from 1M to 64M. For example, 4M would be 4194304.
compatible.rdbms This defines the compatibility setting of the disk group with respect to the database. The default value is 10.1. This value cannot be rolled back to a previous, lower version setting.
compatible.asm This defines the format of the data on the ASM disks with respect to a given database version. Example '11.0'. The default value is 10.1.
disk_repair_time Enables the use of fast disk resync. Valid values are from 0 to 136 years. Support for this attribute is only available if both COMPATIBLE attributes (COMPATIBLE.RDBMS and COMPATIBLE.ASM) are set to 11.1 or higher.

You can query the V$ASM_ATTRIBUTE view to see the individual attributes assigned to a given disk group. Here is an example:

SELECT group_number, name, value
FROM v$asm_attribute
ORDER BY group_number, name;
------------ -------------------- --------------------
           1 au_size              1048576
           1 compatible.asm
           1 compatible.rdbms     11.1.0
           1 disk_repair_time     300M

ASM Disk Discovery

When the ASM instance is started, it will use the paths listed in the ASM_DISKSTRING parameter and discover the disks that are available. These disks can then be added to ASM disk groups which we will discuss in the next section. Once discover is complete and the ASM instance is open, you can review the disks discovered by looking at the V$ASM_DISK view as seen in this example:

column path format a20
set lines 132
set pages 50

select path, group_number group_#, disk_number disk_#, mount_status,
       header_status, state, total_mb, free_mb
from v$asm_disk
order by group_number;

-------------- ------- ------ ------- ------------ -------- ---------- ----------
/dev/raw/raw4        0      1 CLOSED  FOREIGN      NORMAL           39          0
/dev/raw/raw5        0      0 CLOSED  FOREIGN      NORMAL           39          0
/dev/raw/raw3        0      2 CLOSED  FOREIGN      NORMAL           39          0
/dev/raw/raw6        0      2 CLOSED  CANIDATE     NORMAL         2048       2048
ORCL:ASM01_004       1      3 CACHED  MEMBER       NORMAL        34212      30436
ORCL:ASM01_005       1      4 CACHED  MEMBER       NORMAL        34212      30408
ORCL:ASM01_006       1      5 CACHED  MEMBER       NORMAL        34212      30420
ORCL:ASM01_007       1      6 CACHED  MEMBER       NORMAL        34212      30297
ORCL:ASM01_008       1      7 CACHED  MEMBER       NORMAL        34212      30507
ORCL:ASM01_009       1      8 CACHED  MEMBER       NORMAL        34212      30404
ORCL:ASM01_010       1      9 CACHED  MEMBER       NORMAL        34212      30509
ORCL:ASM01_011       1     10 CACHED  MEMBER       NORMAL        34212      30449
ORCL:ASM01_012       1     11 CACHED  MEMBER       NORMAL        34212      30340
ORCL:ASM01_013       1     12 CACHED  MEMBER       NORMAL        34212      30357

In this view there are 3 disks that are not assigned to any group (those with GROUP_# set to 0). These are unassigned disks that ASM has discovered but that have not been assigned to a disk group. Note the mount status of CLOSED on those three disks which also indicates that the disk is not being accessed by ASM. The HEADER_STATUS of FOREIGN indicates that these disks contain data already, and are owned by some process other than ASM (in this case, these are voting disks for a RAC cluster). If the HEADER_STATUS says CANIDATE, as with /dev/raw/rdisk6, then we could add this disk to an ASM disk group.

Notice that most of the disks have a MOUNT_STATUS of CACHED and a HEADER_STATUS of MEMBER. This means that the disk is currently part of an ASM disk group.

There are some cases where the V$ASM_DISK view will not report any disks. For example, on a Windows XP system there may be no raw disks to discover, so the V$ASM_DISK view will simply be blank. This is not a problem, because you can use an existing file system as a location for an ASM disk. This is discussed in the next section on how to add disk groups to ASM.

Some things to be aware of with regards to ASM disk discovery:

  1. ASM can discover no more than 10,000 disks. If you have more than that, ASM will only discover the first 10,000 disks. This can occur when your ASM disk string is not sufficiently restrictive and the directory that you are searching in has a number of raw devices, but many of them are not going to be assigned to ASM.
  2. ASM will not discover disks that contains an operating system partition table.
  3. ASM may discover disks that already contain Oracle data on them (as in our example above with the voting disks).

Adding an ASM Disk Group

Once ASM has discovered the available disks, it is easy to create an ASM disk group. You use the create disk group command to create an ASM disk group. When you issue the command you will assign the disk group it's name, and you will add one or more discovered (unallocated) disks to that disk group. Here is an example of the use of the create disk group command:

failgroup diskcontrol1 DISK
failgroup diskcontrol2 DISK

Let's look at some of the details of this command in a bit more detail next.


In the previous example, we created an ASM disk group using the NORMAL REDUNDANCY parameter. When configuring ASM disk groups you can use one of three different redundancy-setting options:

  • Normal: Typically employs two way mirroring by default, and thus requires two failgroups be allocated.
  • High: Typically employs three way mirroring by default, and thus requires three failgroups be allocated.
  • External: Does not employ any mirroring or striping. This setting is typically used when the disk group is being assigned to an external disk that is attached to some device that already employs some disk redundancy.

The redundancy setting defines attributes for that disk group including what kind of striping occurs and if the data will be mirrored or not. You can take the default template setting, or you can assign another ASM template to a given disk group using the . For example, if you assigned the

The following list gives you some guidance to the type of configuration that will result depending on the redundancy setting you use:

Template nameStripingMirroring when using a normal redundancy disk groupMirroring when using a high redundancy disk groupMirroring when using an external redundancy disk group
Controlfile Fine 3-Way Mirroring 3-Way Mirroring No Mirroring
Datafile Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Onlinelog Fine 2-Way Mirroring 3-Way Mirroring No Mirroring
Archivelog Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Tempfile Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Backupset Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Parameterfile Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Dataguardconfig Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Flashback Fine 2-Way Mirroring 3-Way Mirroring No Mirroring
Changetracking Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Dumpset Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Xtransport Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring
Autobackup Coarse 2-Way Mirroring 3-Way Mirroring No Mirroring

So, in the earlier example of the creation of a disk group, we would have ended up with 2 way mirroring and coarse striping. In this case, with the two way mirroring, everything that would be written to the /devices/diska1 device would also be mirrored to the /devices/diskb1 device.

In the previous example we used the failgroup parameter of the create diskgroup command to designate a logical disk group structure within the diskgroup itself. Thus, in the previous example there were two failgroup groups defined, each of which had one disk assigned to it. If you are using a disk group that is doing 2-Way mirroring, then you will need at least two failgroup entries in each create diskgroup command. If you do not define a failgroup, Oracle will assign each disk to it's own failgroup.

We can opt for three-way mirroring by using the high redundancy parameter. In this case you will also need an additional failgroup entry for each mirror as seen in this example:

failgroup diskcontrol1 DISK
'/devices/diska1' NAME diska1
failgroup diskcontrol2 DISK
'/devices/diskb1' NAME diskb1
failgroup diskcontrol3 DISK
'/devices/diskc1' NAME diskc1;

You might have noticed the name clause in the create diskgroup command example earlier. You can also name the disks being assigned to the ASM disk group using the name clause of the create diskgroup command. Failure to use the name clause will result in each disk receiving it's own system default assigned name.

The previous examples assumed that you were creating a diskgroup on a raw partition. Of course, ASM can support file systems that have already been allocated via the operating system. To create ASM disk groups on cooked file systems we need to create a file on the file system so that we can point ASM at that file. When using non-raw file systems, we need to set the parameter ASM_DISKSTRING to the location we want to create the ASM disks devices:

C:\>mkdir c:\oracle\asm_disk
Sqlplus sys as sysdba
SQL>Alter system set ASM_DISKSTRING='c:\oracle\asm_disk\_file*';

We will also need to set a hidden parameter called _ASM_ALLOW_ONLY_RAW_DISKS to allow ASM to see non-raw disks. This is a hidden parameter so use it with caution:

SQL>alter system set "_asm_allow_only_raw_disks"=false scope=spfile;

Next, we need crate the files that ASM will see as disks. To do this, we can use a cool little pearl program like this one (on UNIX you could use the dd utility for example):

my $s='0' x 2**20;

open(DF1,">C:/oracle/asm_disk/_file_disk1") || die "Cannot create file - $!\n";
open(DF2,">C:/oracle/asm_disk/_file_disk2") || die "Cannot create file - $!\n";
open(DF3,">C:/oracle/asm_disk/_file_disk3") || die "Cannot create file - $!\n";
open(DF4,">C:/oracle/asm_disk/_file_disk4") || die "Cannot create file - $!\n";

for (my $i=1; $i<100; $i++) {
  print DF1 $s;
  print DF2 $s;
  print DF3 $s;
  print DF4 $s;


And execute the script. Oracle comes with a useful Pearl interpreter:


Once this is complete, check the c:\oracle\asm_disk directory and you will see files:

 Volume in drive C has no label.
 Volume Serial Number is 08DE-E1AB

 Directory of C:\oracle\asm_disk

01/27/2007  10:27 PM    <DIR>          .
01/27/2007  10:27 PM    <DIR>          ..
01/27/2007  10:27 PM       103,809,024 _file_disk1
01/27/2007  10:27 PM       103,809,024 _file_disk2
01/27/2007  10:27 PM       103,809,024 _file_disk3
01/27/2007  10:27 PM       103,809,024 _file_disk4
               4 File(s)    415,236,096 bytes
               2 Dir(s)  68,573,462,528 bytes free

Now, ASM should be seeing the new disks. We can tell by querying the V$ASM_DISK view as seen here:

SELECT group_number, disk_number, mount_status,
header_status, state, path
FROM   v$asm_disk;

And the results:

------------ ----------- ------- ------------ -------- ------------------------------

Note that our four disks now show up as available disks in ASM. We can now create disk groups using these disks:

failgroup diskcontrol1 DISK
'c:\oracle\asm_disk\_file_disk1' NAME file_diska1
failgroup diskcontrol2 DISK
'c:\oracle\asm_disk\_file_disk2' NAME file_diskb1;

We can see the resulting disk group in the v$ASM_DISKGROUPS view:

SQL> select group_number, name from v$ASM_DISKGROUP;

------------ ------------------------------
           1 COOKED_DGROUP1

When you create an ASM disk group, Oracle will add that disk group to the ASM_DISKGROUPSparameter if you are using an SPFILE. If you are not using an SPFILE then you will need to manually add the disk group to the ASM_DISKGROUPSparameter. The ASM_DISKGROUPSparameter tells Oracle which disk groups it should mount when the ASM instance is started. You can see the ASM_DISKGROUPSparameter setting by using the show parameter command from SQL*Plus as seen here:

SQL> show parameter ASM_DISKGROUPs

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------------------
ASM_DISKGROUPs                       string      COOKED_DGROUP1, SP_DGROUP2

If you do not add the disk group to the ASM_DISKGROUPS parameter, then you will need to manually mount the disk group.

We now have an ASM disk group that is ready to have Oracle files created on it.


Note the striping column in the table we presented earlier in the section on redundancy. There are two values there, FINE and COARSE. This refers to the strip size that ASM applies to the disks that the disk groups are assigned to. If FINE striping is selected, the ASM will use a 128KB stripe size. If coarse is selected then Oracle uses a 1MB stripe size.


When you create an ASM disk group, Oracle will assign a default template to that disk group (see the earlier list with the default templates listed). A template is simply a named collection of attributes. For example, if you create a diskgroup using the default template and then create datafiles in that disk group, the datafile template will define the redundancy and striping for that data.

There may be cases where you want to define your own template for a disk group. In this case you can you will need to first create the disk group, and then alter the disk group using the add template parameter of the alter diskgroup commands as seen in this example:

failgroup diskcontrol1 DISK
'c:\oracle\asm_disk\_file_disk3' NAME file_diska1
failgroup diskcontrol2 DISK
'c:\oracle\asm_disk\_file_disk4' NAME file_diskb1;

ADD TEMPLATE new_template
ATTRIBUTES (mirror);

After the mirror template has been added, you can create files in that disk group using the new template.

One note on user defined templates. When you add a template to a disk group, the template can not be retroactively applied to files already in that disk group. As a result you will need to use RMAN to backup and then restore files that already exist in the disk group in order for them to take on the attributes of the new template.

You can see the templates associated with a given disk group by querying the V$ASM_TEMPLATE view as seen in this example:

SQL> select * from v$asm_template
  2  where group_number=2;

------------ ------------ ------ ------ - --------------------
           2            0 MIRROR COARSE Y PARAMETERFILE
           2            1 MIRROR COARSE Y DUMPSET
           2            2 HIGH   FINE   Y CONTROLFILE
           2            3 MIRROR COARSE Y ARCHIVELOG
           2            4 MIRROR FINE   Y ONLINELOG
           2            5 MIRROR COARSE Y DATAFILE
           2            6 MIRROR COARSE Y TEMPFILE
           2            7 MIRROR COARSE Y BACKUPSET
           2            8 MIRROR COARSE Y AUTOBACKUP
           2            9 MIRROR COARSE Y XTRANSPORT
           2           10 MIRROR COARSE Y CHANGETRACKING
           2           11 MIRROR FINE   Y FLASHBACK
           2           12 MIRROR COARSE Y DATAGUARDCONFIG
           2           13 MIRROR COARSE N NEW_TEMPLATE

In this output note that the new template (new_template) has been created and is ready for use. You can drop a template with the alter diskgroup command using the drop template parameter as seen in this example:

DROP TEMPLATE new_template;

And you can alter a user defined template with the alter template parameter of the alter diskgroup command. Notice in this example we are actually changing one of the attributes of the default templates. You cannot drop the default templates, but you can modify them as seen here:

ATTRIBUTES (coarse);