Oracle Rant

I just wanted to share an experience that I had with Oracle ASM that made my life a breeze. ASM gives the DBA more control and flexibility in dealing with storage. It even has some excellent performance benefits.

Well, I would also like to add to the list that it also proactively cures headaches and stress! This is why. We have an IBM Shark that is going off of lease. We needed to move the database to Hitachi storage. The problem was we needed to do it fast and we couldn’t get the application owners to give us a change window in the alloted time frame. The most they would give us was 2 hours and this was a multi-terabyte database. It wasn’t happening!

So how did Oracle ASM save me? Simple! I just added the new disks to my existing diskgroup and let ASM automatically rebalance the disks. I let this job run overnight with virtually no impact to application performance. I could have done it with a higher rebalancing factor but that had a greater chance to impact the application. Instead, I just did it with a power of 1 which was the default.

Once the job finished rebalancing, I then moved to drop the old disks. Please make sure you add more than enough space in new disks to allow you to remove the old ones. With the disks being dropped, Oracle moved all extents off those disks and neatly rebalanced it on the ones that were left. The job took a day to complete and after ASM was done with them, the Unix SA and SAN admin went ahead and removed them, all the while the application maintained 100% uptime and solid performance.

ASM has it’s limitations such as having to use RMAN to do backups and many of your shell scripts won’t work against it without being rewritten to use sqlplus instead or RMAN, but even RMAN is an improvement over traditional backups. I wouldn’t even call this a limitation but a strength. Oh well, I’ll just stick with ASM on this one. Definitely take the time to get up to speed on ASM! It’s a lifesaver.
 

Oracle Automatic Storage Management was introduced in Oracle 10g and improved upon in Oracle 11g. It’s the new storage filesystem from Oracle that runs on every platform. The idea behind ASM was to create a filesystem that was designed and integrated for the Oracle database. It gives high performance, easier administration, more flexibility, and clustering capabilities for Oracle RAC, and lower cost. It’s an exciting new technology that every Oracle DBA should look into. Instead of managing files you manage disk groups which are pools of storage. The book was written by a group of authors who have great insite into ASM including the Director of Development for ASM, Rich Long. They explain the basics of the storage stack. They then talk about configuring ASM and what the gotchas are for platforms like Solaris, AIX, Linux, Windows, and HP-UX. They authors even elaborate on multi-pathing software like HDLM and EMC Powerpath. They even talk in detail about the ASMLIB utility that is used for managing disks for ASM on Linux. Next, they discuss Diskgroups and Failure Groups in ASM. They then get into ASM administrations such as Files, Aliases, Templates, Rebalancing, Space Allocation, ASMCMD, Extents, Striping, Mirroring. They then get into deployment and Storage Array Configurations. The book finally ends with a Troubleshooting Guide with a clear explanation of the Alert Log files for ASM and some scripts that can be used to maintain an ASM environment.  I would highly recommend this book for any DBA that will be working with ASM and / or RAC. The high performance, ease of use,  and low cost make it a very attractive solution. This book will teach you everything you need to know about ASM and make you an ASM expert. After learning ASM, it also makes an excellent reference. I give it a perfect rating of 5 stars!

I wanted to pass on a tip to anyone doing ASM or CRS or both on Sun Solaris. When you install CRS, ASM, or both, you have to use raw devices. CRS needs the raw devices for the OCR and voting disks. ASM needs the raw devices so that it can control them and offer them in storage pools known as disk groups. Solaris uses a Virtual Table of Contents (VTOC) file that it uses to share devices between servers. When the disk is formatted by your Solaris SA, you need to make sure they do not use the first cylinder. Instead of using cylinder 0 to whatever, they need to use from cylinder 1 to whatever, leaving cylinder 0 alone. That way, when you dd the disks it will not cause the disks to “disappear”. My Solaris admin and I went through it about 4 times till we found the catch. The documentation on metalink is a little fuzzy so hopefully this helps some people out.

Also, with raw devices, I would suggest using an mknod command to label the disks so that it is much easier to support in the future.