Extending ASM Space for an Oracle DB

Extending an ASM Disk Group

There are 3 options how to provide more disk space to the database.

1. Extend the underlying LUN provided by the NetApp Filer.
2. Create another disk group and create new data files only in this group.
3. Add another disk to the existing disk group.

We descided not to go with the first option because in order for the operating system to recognize the new extended size of the LUN, we would have to reboot the system.

For obvious reasons the 2nd option is not very handy. It would require the administrator to allways make shure only the new disk group is being used and turn autoextend off on all datafiles in the old group as soon as ist is 100% full etc.

So the 3rd option seemed most promising. However it required some planing in advance:

ASM tries to spread/stripe data equally over all disks in a diskgroup. In order for this to work propperly all disks in one ASM disk group have to be of the same size.
We therefore used a relatively small size of 100 GB for the first disk in the disk group keeping in mind that we will be able to add more 100GB chunks as needed.

 In order to achive the desired result: another 100 GB disk in the ASM disk group, several things had to be accomlished

Finding 100 GB of free space in the NetApp Filer

Looking in the webinterface of the filer, clicing on Aggregates -> Manage I saw that there is only little space left and it will not be enough for my 100 GB disk. Therefore I had to do some spring cleaning.

1. Disable Snapshots on volumes that do not require snapshots.
   eg. we user rman to backup our oracle databases. So all volumes used for oracle database do not require snapshots.
1. Find out what snapshots exist:
   

   $ snap list

2. When you find a volume that does unecessary snapshots:
   

   $ snap sched <vol> 0 0 0

3. Now you delete all snapshots for the volume:

   $ snap delete -a <vol>

2. Delete/Disable unused volumes
   I found a couple of volumes that facilitated systems that where taken offline long ago.
1. In the webinterface "offline" all LUNs belonging the the volume
2. In the webinterface "disable" the volume

Creating a new LUN in the NetApp Filer

A LUN resides in a volume. Adding a new LUN requires that the volume has sufficiant freespace in order to house the LUN.

1. Extending the Volume
   In the Webinterface click on the volume and extend it
2. Create a new LUN
   This also works well in the webinterface using the wizard.
3. Assign the LUN the the appropriate initiator group.
   So the Host will be allowed to see the LUN, it will have to be assigned to the same initiator group as the other LUN that makes up the first disk in the ASM disk group.

Making the host operating system aware of the new LUN

This took me quite some time to figure out. None of the onboard tools seemed to be able to do the job. No chance to reboot the system.

The System has the following configuration:

• FSC Server hardware
• 2 redundant Emulex FC Host Adapters
• Linux RHEL5
• NetApp Filer

 I was quite hesitant to use it, since it is a prodution system with a high continuous workload with substantial I/O. If the rescan of the LUNs would interrupt the I/O operations it might crash the systems or may even result in corruptions on the database. After some testing in a sendbox I gave it a try:

$ ./lun_scan -s all

No errors on the console, no erros in the demesg, no errors in the alert.log neither of the ASM nor the DB. Looks good!

dmesg reported that it has discoverd a new disk /dev/sdu. So lets see if the multipath deamon has also detected it:

$ multipath -v2
$ multipath -ll

Yes! Here it is:

360a98000486e566f4b6f4f6b53304c63dm-6 NETAPP,LUN
[size=100G][features=1 queue_if_no_path][hwhandler=0]
\_ round-robin 0 [prio=8][active]
 \_ 3:0:0:0 sdr 65:16 [active][ready]
 \_ 4:0:0:0 sdt 65:48 [active][ready]
\_ round-robin 0 [prio=2][enabled]
 \_ 3:0:1:0 sds 65:32 [active][ready]
 \_ 4:0:1:0 sdu 65:64 [active][ready]

Making the disk accessible through ASM-Lib

If you are on Linux Oracle recomends using ASMlib for all reasons (performance,stability,...) So we have ASMlib installed and just need to add the new disk to it.

$ /etc/init.d/oracleasm querydisk /dev/mapper/360a98000486e566f4b6f4f6b53304c63
Device "/dev/mapper/360a98000486e566f4b6f4f6b53304c63" is not marked as an ASM disk

No it's not in user yet by ASM. So let's turn it into an ASM disk

/etc/init.d/oracleasm createdisk DATAVOL02 /dev/mapper/360a98000486e566f4b6f4f6b53304c63

And now?

# /etc/init.d/oracleasm querydisk /dev/mapper/360a98000486e566f4b6f4f6b53304c63
Device "/dev/mapper/360a98000486e566f4b6f4f6b53304c63" is marked an ASM disk with the label "DATAVOL02"

OK, mission accomplished!

Adding the new ASM disk to the existing diskgroup.

This was very easy. Just used Oracle Enterprise Manager. Click on the ASM-Instance, click on the disk group, cick add. Select the right disk -> OK.

Done!