Just in case you try to add disks to an existing ASM disk group using syntax like this:
alter diskgroup data
add disk '/dev/xvdd1'
add disk '/dev/xvde1';
You may get error messages like these:
ORA-15032: not all alterations performed
ORA-15031: disk specification '/dev/xvde1' matches no disks
ORA-15025: could not open disk '/dev/xvde1'
ORA-15056: additional error message
Linux-x86_64 Error: 13: Permission denied
Additional information: 42
Additional information: -1614995373
Additional information: 1730318408
ORA-15031: disk specification '/dev/xvdd1' matches no disks
ORA-15025: could not open disk '/dev/xvdd1'
ORA-15056: additional error message
Linux-x86_64 Error: 13: Permission denied
Additional information: 42
Additional information: 87328232
Additional information: 8192
Solution: Use the ASM disk names as given when creating them with oracleasm:
alter diskgroup data
add disk 'ORCL:VOL3'
add disk 'ORCL:VOL4';
Here VOL3 and VOL4 are the names given when creating the ASM-disk with oracleasm:
oracleasm createdisk VOL3 /dev/xvdd1
oracleasm createdisk VOL4 /dev/xvde1
The initialization parameter asm_diskstring is empty as is default.
The error messages from OS (Linux in this case) may lead you to think that there is something wrong with the owner or attributes of the devices you've just created, even they have the same permissions as the devices previously allocated to ASM... Then when you against reason set the owner and group to be like 'oracle:dba' the error message from Linux does not show up, but you will still get error messages like this:
ORA-15032: not all alterations performed
ORA-15031: disk specification '/dev/xvde1' matches no disks
ORA-15014: location '/dev/xvde1' is not in the discovery set
ORA-15031: disk specification '/dev/xvdd1' matches no disks
ORA-15014: location '/dev/xvdd1' is not in the discovery set
A note on MOS with id 603210.1 is one example of this confusion, it contains this command indicating that it is OK to use the physical device name (which it may be in certain environments for what I know):
create diskgroup DATADG external redundancy disk '/dev/sda14';
I think this is one of several reasons why certain un*x guys used to old and mature volume managers and file systems do not easily fall in love with ASM... Once one has passed these initial obstacles I find ASM OK to work with, even for non-RAC databases. It usually shortens the path from getting a LUN allocated on the SAN or whatever until more free space is available to the tablespace in the database.
[This testing was done on a Oracle VM guest, created from an OVM template downloaded from Oracle. It comes with OEL 5 64-bit and version 10.2.0.4 of the database. Oracle calls this OS for JeOS (Just enough OS), but for some reason it does not come with the 'man' command, so for me it is JneOS.]
