Most Oracle DBAs who are familiar with Oracle Automatic Storage Management (ASM) choose to implement Oracle ASM in their environments. Why you may ask? Well, Oracle ASM takes the burden off of your storage management.


Do you remember the time when you put your Oracle database on a file system such as VxFS, JFS, JFS2, or UFS on UNIX operating system back in the days? What happens when your file system runs out of disk space? Well, you create another file system/mount point in order to add more Oracle data files. And what about performance, you use something on UNIX called (LVM) to take advantage of striping across multiple LUNs. And how did you expand the logical volume? You add more physical LUNs to the volume group and extend your logical volume and run the file system resize (online if you’re lucky). And of course, when you run the “df” command, the output lists a bunch of mount points just for a single database. Imagine automating certain tasks via shell scripts with this many mount points on your database server. Your System Admin and you (DBA) would spend a lot of time strategizing disk space management, taking away your precious time as a DBA to do real work for your business users.


Oracle came up with a solution for disk management starting with Oracle 10g. It is called Automatic Storage Management (ASM). Oracle ASM is a cool feature in such a way that it takes the guess work out of disk management. You no longer have to manage your file system with LVM. Plus there is no file system tuning with ASM since ASM runs on block devices at the operating system level.


Fast forward to the year 2013, many Oracle shops are moving fast from other UNIX flavors to Linux (especially Oracle Linux or RHEL). This makes it even easier to manage your Oracle environments whether it is a single instance database or Real Application Cluster (RAC). With Oracle ASM, there is no need to have a cluster file system such as VERITAS CFS or OCFS2 to name a few. One thing I have to say about running Oracle on Linux is that Oracle has an ASMLib package that allows you to name your ASM disks. This makes it a lot easier to manage ASM disks instead of mpath devices or /dev/rdsk/cXtYdZ (for you UNIX guys/gals out there). Oracle ASM also makes it easy to add or remove disks from the ASM disk groups (works great for SAN migration). It also makes it easy to resize existing ASM disks provided that you don’t use disk partitioning. When using Oracle ASM, it is best practice to use the whole disk. I will discuss adding/removing ASM disks and resizing ASM disks in another post. Stay tuned….


Now, enough said about Oracle ASM benefits. Let’s talk about running Oracle ASM on Nimble Storage and see how easy it is to setup. Oracle ASM can run on any storage but I am using Nimble Storage in this post since I have a luxury of doing so.


In this simple configuration, I have a single VM running on Oracle Linux with 2 Oracle ASM disk groups (one for OCR and one for my database). I only created 3 volumes from the Nimble Storage and present them to my VM. After configuring multipathing, you should see something similar to this.


Now, with ASMLib package, I just create the ASM disks via the command /etc/init.d/oracleasm createdisk. Here is the output after creating the disks.


Next, I created two ASM disk groups. They would look something like this after creation.


Now that the ASM disk group for the database is ready for use, you just specify the “+DATADG” keyword when creating your database or tablespaces. Oracle will use OMF feature to manage the data files for you.