Tim Hall had the idea that as many people as possible would write a small blog post about their favorite Oracle feature and we all post them on the same day. Here is my favorite feature: ADVM – The Oracle ASM Dynamic Volume Manager.
So, what is it? The docs tell you this: “Oracle ASM Dynamic Volume Manager (Oracle ADVM) provides volume management services and a standard disk device driver interface to clients. File systems and other disk-based applications send I/O requests to Oracle ADVM volume devices as they would to other storage devices on a vendor operating system.”
The easy to understand version is this: It enables us to use regular file systems on top of ASM.
Does is make sense to use it? When you have ASM running on the host or all the hosts of a Grid Infrastructure cluster anyway then it definitely makes sense. ASM will do all the mirroring and striping for you so there is no need to use another technology to achieve that when you can create ADVM volumes and create file systems on top of these. Although the most common scenario is to create an ACFS file system on top of the volumes you are actually not limited to that. Lets do a short demo.
Lets say we have these devices available for use by the grid user:
[[email protected] ~] ls -la /dev/sd[b-f]* brw-rw----. 1 root disk 8, 16 Oct 10 17:54 /dev/sdb brw-rw----. 1 grid asmadmin 8, 17 Oct 10 18:10 /dev/sdb1 brw-rw----. 1 root disk 8, 32 Oct 10 17:54 /dev/sdc brw-rw----. 1 grid asmadmin 8, 33 Oct 10 18:10 /dev/sdc1 brw-rw----. 1 root disk 8, 48 Oct 10 17:54 /dev/sdd brw-rw----. 1 grid asmadmin 8, 49 Oct 10 18:10 /dev/sdd1 brw-rw----. 1 root disk 8, 64 Oct 10 17:54 /dev/sde brw-rw----. 1 grid asmadmin 8, 65 Oct 10 18:10 /dev/sde1 brw-rw----. 1 root disk 8, 80 Oct 10 17:54 /dev/sdf brw-rw----. 1 grid asmadmin 8, 81 Oct 10 18:10 /dev/sdf1
We want to use “/dev/sde1” for our new ADVM volume. What we need is an ASM diskgroup in a first step because for creating an ADVM volume you’ll need a ASM diskgroup where you can place your volume on:
[email protected]:/home/grid/ [+ASM1] sqlplus / as sysasm SQL> create diskgroup ADVM external redundancy disk '/dev/sde1'; Diskgroup created. SQL>
Ok, fine. How can we proceed with creating a volume? Quite easy:
[email protected]:/home/grid/ [+ASM1] asmcmd volcreate -G ADMV -s 2g VOLADVM ORA-15032: not all alterations performed ORA-15221: ASM operation requires compatible.asm of 184.108.40.206.0 or higher (DBD ERROR: OCIStmtExecute)
Easy to fix:
[email protected]:/home/grid/ [+ASM1] sqlplus / as sysasm SQL> alter diskgroup ADVM set attribute 'compatible.asm'='12.1'; Diskgroup altered. SQL>
Lets try again:
[email protected]:/home/grid/ [+ASM1] asmcmd volcreate -G ADMV -s 2g VOLADVM [email protected]:/home/grid/ [+ASM1]
Perfect. Now I have a volume visible to the operating system:
[email protected]:/home/grid/ [+ASM1] ls -la /dev/asm/*advm* brwxrwx---. 1 root asmadmin 252, 115201 Oct 10 18:20 /dev/asm/voladvm-225
On top of this volume we can now create file systems. The natural one would be ACFS:
[[email protected] ~] mkfs.acfs /dev/asm/voladvm-225 mkfs.acfs: version = 220.127.116.11.0 mkfs.acfs: on-disk version = 39.0 mkfs.acfs: volume = /dev/asm/voladvm-225 mkfs.acfs: volume size = 2147483648 ( 2.00 GB ) mkfs.acfs: Format complete.
But in fact every other file system the operating system supports is possible, too:
[[email protected] ~] mkfs.xfs /dev/asm/voladvm-225 meta-data=/dev/asm/voladvm-225 isize=256 agcount=4, agsize=131072 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=524288, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
Quite cool, isn’t it? Whatever file system your operating system supports can be put on ASM disk groups …