10G Features I Hope I'll Like
Oracle Backup - Oracle's New Tape Management System
Oracle10G has its own tape managment system that integrates directly into RMAN. Since we are an RMAN shop, we are going to kick off another project to determine if we should begin using Oracle Backup as our tape management system.
I figure that its definitely worth further investigation. What better software can you use to back up Oracle than Oracle? Our current tape management system is expensive in both licensing and maintenance costs. We'll need to determine if the benefits that Oracle Backup provides outweighs the costs of us supporting two different tape management systems.
Automatic Storage Management (ASM)
If you have read my past blogs, you understand what ASM does. For those of you that haven't, here's a quick refresher. ASM is actually an Oracle instance that manages disk. Instead of using a file management system, you feed the disks into ASM which then provides the traditional mirroring and striping that we all know and love. You create ASM disk groups and place your Oracle data files, temp files and online redo logs in the ASM disk groups.
We are an EMC shop, through and through. We have cabinets and cabinets of Symmetrix and Clariion disks. We are also an IBM shop running 5.2 and 5.3 of AIX. Since we currently use AIX raw devices, we won't have much of a learning curve when we move to ASM. We will also be continuing to let EMC provide the mirroring and striping but we also want ASM to do it's own 1 MEG striping.
EMC has the concepts of LUNs and METALUNs. A LUN is a chunk of a disk that is addressed by the SCSI Logical Unit Number (LUN). A single EMC disk can be split into several LUNs. A METALUN is a collection of LUNs that act as single entity and are presented to the application (in this case, Oracle) as a single component. EMC provides a myriad of alternatives for striping and mirroring. A common practice here at Giant Eagle is to carve up the EMC disks into METALUNs and stripe them in 64 MEG stripes.
OK, why are we interested in ASM if we already use RAW disk and will continue to let EMC mirror and stripe? Isn't this overkill? How about a mutli-part answer to that question:
- Some of our servers have several small databases on them. We will create one ASM instance on the server and be able to administer all of the database's datafiles with ASM. We'll create separate disk groups for tables, indexes, online redo logs, temp files, undo files etc. and place data from multiple databases within the same group.
- ASM will provide disk loadbalancing by automatically moving data to a new disk that is added to the disk group. This is a HUGE benefit for ASM. When we want to add a disk to improve performance by spreading I/O among more drives or increase a disk group's storage capacity, we can do it without taking the system down. In the past this required an extended outage to allow our disk gurus to relayout the disk subsystem. BIG IMPROVEMENT. We'll stripe the daylights out of everything and when we need to add additional disk, we can just add it on the fly.
- ASM allows us to do a finer grain of striping than we can with EMC and raw devices. I would much rather prefer a 1 MEG stripe over our traditional 64 MEG EMC stripe for performance.
- I want to administer my own disk. So there.
Until Next Time
Chris
