The starting point of this blog post is a talk that I had with my twitter friend Martin Berger (@martinberx): He suggested me to test the Flex ASM behavior with different ASM disks path per machine.

As the documentation states:


Different nodes might see the same disks under different names, however each instance must be able to use its ASM_DISKSTRING to discover the same physical media as the other nodes in the cluster.

Not saying this is a good practice but as everything not forbidden is allowed let’s give it a try that way:

  • My Flex ASM lab is a 3 nodes RAC.
  • The ASM_DISKSTRING is set to /dev/asm* on the ASM instances.
  • I’ll add a new disk with udev rules in place on the 3 machines so that the new disk will be identified as:
  • /dev/asm1-disk10 on racnode1
  • /dev/asm2-disk10 on racnode2
  • /dev/asm3-disk10 on racnode3

As you can see, the ASM_DISKSTRING (/dev/asm*) is able to discover this new disk on the three nodes. Please note this is the same shared disk, it is just identified by different path on each nodes.

On my Flex ASM lab, 2 ASM instances are running:

srvctl status asm
ASM is running on racnode2,racnode1

Let’s create a diskgroup IOPS on this new disk (From the ASM1 instance):

. oraenv
The Oracle base remains unchanged with value /u01/app/oracle
[oracle@racnode1 ~]$ sqlplus / as sysasm

SQL*Plus: Release Production on Tue Jul 16 12:03:59 2013

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release - 64bit Production
With the Real Application Clusters and Automatic Storage Management options

SQL> create diskgroup IOPS external redundancy disk '/dev/asm1-disk10';

Diskgroup created.

SQL> exit
Disconnected from Oracle Database 12c Enterprise Edition Release - 64bit Production
With the Real Application Clusters and Automatic Storage Management options

[oracle@racnode1 ~]$ srvctl start diskgroup -g IOPS

[oracle@racnode1 ~]$ srvctl status diskgroup -g IOPS
Disk Group IOPS is running on racnode2,racnode1

So everything went fine. Let’s check the disk from the ASM point of view:

SQL> l
  1  select
  2  i.instance_name,,d.path
  3  from
  4  gv$instance i,gv$asm_diskgroup g, gv$asm_disk d
  5  where
  6  i.inst_id=g.inst_id
  7  and g.inst_id=d.inst_id
  8  and g.group_number=d.group_number
  9  and'IOPS'
SQL> /

INSTANCE_NAME    NAME                           PATH
---------------- ------------------------------ --------------------
+ASM1            IOPS                           /dev/asm1-disk10
+ASM2            IOPS                           /dev/asm2-disk10

As you can see +ASM1 discovered /dev/asm1-disk10 and +ASM2 discovered /dev/asm2-disk10. This is expected and everything is ok so far.

Now, go on the third node racnode3, where there is no ASM instance.

Remember that on racnode3 the new disk is /dev/asm3-disk10. Let’s connect to the NOPBDT3 database instance and create a tablespace IOPS on the IOPS diskgroup.

SQL> create tablespace IOPS datafile '+IOPS' size 1g;

Tablespace created.

Perfect, everything is ok.  Now check v$asm_disk from the NOPBDT3 database instance:

SQL> select path from v$asm_disk where path like '%10';


As you can see the NOPBDT3 database instance is linked to the +ASM2 instance (as it reports /dev/asm2-disk10)

But the NOPBDT3 database instance located on racnode3 access /dev/asm3-disk10.

SQL> select instance_name from v$instance;


SQL> !ls -l /dev/asm2-disk10
ls: cannot access /dev/asm2-disk10: No such file or directory

SQL> !ls -l /dev/asm3-disk10
brw-rw----. 1 oracle dba 8, 193 Jul 16 15:35 /dev/asm3-disk10

Ooooh wait !  The NOPBDT3 database instance access the disk /dev/asm3-disk10 which is not recorded into gv$asm_disk.

So what if I launch SLOB locally on the NOPBDT3 database instance, are the metrics recorded ?

First, let’s setup SLOB on the IOPS tablespace:

[oracle@racnode3 SLOB]$ ./ IOPS 3

Now, launch SLOB and check the I/O metrics thanks to my asmiostat utility that way:

 ./ -type=asmiostat -show=inst,dbinst -dg=IOPS

With the following output:


As you can see the metrics have not been recorded, while the IOPs have been done (/dev/asm3-disk10 is /dev/sdm):

egrep -i "sdm|device" iostat.out | tail -4
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sdm               0.00     0.00  101.64    0.00     0.79     0.00    16.00     1.80   17.74   6.05  61.52
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
sdm               0.00     0.00  109.34    0.00     0.85     0.00    16.00     1.82   16.66   5.70  62.28

Of course the same test launched from the NOPBDT2 database instance linked to the +ASM2 instance,would produce the following output:


So the metrics are recorded as the database Instance is doing the IOPS on devices that the ASM instance is aware of (NOPBDT2 linked to +ASM1 would produce the “invisible” metrics).

Important remark:

The metrics are not visible from the gv$asm_disk view (from the ASM or the database instance), but there is a place where the metrics are recorded: The gv$asm_disk_iostat view from the database instance (Not the ASM one).


The “invisible” I/O (metrics not recorded into the gv$asm_disk view) issue occurs if:

  1. you set different disks path per machine (so per ASM instance) in a Flex ASM (12.1) configuration.
  2. and the database instance is attached to a remote ASM instance (then using different path).

So I would suggest to use the same path per machine for the ASM disks in a Flex ASM (12.1) configuration to avoid this issue.

Update: The asmiostat utility is not part of the script anymore. A new utility called has been created. See “ASM metrics are a gold mine. Welcome to, a new utility to extract and to manipulate them in real time” for more information.