There's a lot of talk about ASM, but what the heck is it really? ASM is effectively an abstraction layer, allowing your Oracle database to work with abstract space called diskgroups, instead of datafiles directly. This provides lots of benefits, but also requires learning some new concepts, commands, utilities, and administration tasks. So take a look at what it solves, and what it takes to manage and weigh the pros and cons before diving in with your production systems.
Why Was It Created?
The best way to answer this question is to go right to the source, Bill Bridge the original architect of Automatic Storage Management. In the Oracle Press title, Oracle ASM, Bill provides a forward where he discusses the problems with using vendor specific OS filesystems to manage Oracle datafile placement:
1. for arch logs & backups, OS vendors don't provide shared disk filesystem
2. logical volume managers hide the location of files making it difficult to manage disk I/O and provide good stats
3. existing lvm's don't work well with over 100 disks
4. OS's and Oracle don't handle databases well that have 1000's of datafiles
5. naming becomes difficult with large number of datafiles
6. features, and filesystem limitations vary across different OSs
7. users at the OS level can touch Oracle files with standard utilities, without Oracle knowing
So, he set out to solve these problems by building Oracle's own filesystem. His intention was to provide these features:
1. tightly integrated with Oracle, and work with clusters (then parallel server)
2. new storage automatically used, managed as disk unit or disk group
3. thousands of disks supported
4. files won't have names, and will be hidden from the OS
Who Needs It?
A quick look at the problems and solutions above should help you determine who ASM is targeted at. For starters, it was built to handle the very large databases now coming online. So if that includes your shop, you're probably already looking at it, or starting to implement ASM. If you have smaller databases, with fewer datafiles, you may still want to consider it given a few considerations.
1. You'll have some new technology to get familiar with, and should start by setting it up in your dev environment, and do some testing for a few months.
2. If you want to squeeze out more performance from your existing disk subsystem, and get better statistics for forcasting disk I/O.
3. If you're using RAC, ASM is something to consider.
ASM is managed by an instance, much like an Oracle database. However the initialization parameters are much more limited and the startup process is simpler.
a. Set your ORACLE_SID to +ASM1
b. Edit init.ora
# as opposed to RDBMS for a normal Oracle instance INSTANCE_TYPE=ASM # these names will be used in place of datafile names when you create tablespaces ASM_DISKGROUPS=SEAN, AARON processes=100 # this parameter is platform specific and is the path to the raw disk device ASM_DISKSTRING='/dev/cciss/c0d0p1' # on 11g you should use diagnostic_dest instead of these background_dump_dest=/opt/oracle/admin/+ASM/bdump' core_dump_dest=/opt/oracle/admin/+ASM/cdump' user_dump_dest=/opt/oracle/admin/+ASM/udump'
c. start the ASM instance
$ sqlplus / as sysdba SQL> startup
d. create diskgroups
SQL> create diskgroup SEAN disk '/dev/cciss/c0d0p1';
e. example tablespace creation
As you might guess, creating a tablespace will change slightly. The default method looks like this:
SQL> create tablespace sean_space datafile '+SEAN' size 1GB;
However, consider this great feature. If in your database init.ora file you set the parameter
then you can do this:
SQL> create tablespace sean_space;
Then let Oracle do the rest. In both cases, you'll find that the paths of files listed in v$datafile will be relative to the abstract +SEAN diskgroup, not a real OS datafile.
f. And Way Beyond
Of course simplifying filenames and tablespace creation is really only the tip of the iceberg for what ASM can do for you. It can also provide a level of redundancy as well.
In database speak, external redundancy is basically when you have redundancy at the hardware level (RAID) or other method outside of what Oracle can see. In other words if the asm_diskstring devices are themselves logical, hiding the physical disks behind some hardware layer of redundancy, then you have external redundancy.
However, if you don't already have this redundancy, ASM can provide it. You can specify redundancy, failure groups, and a whole host of other options to protect against loss of one or more disks, controllers, or even whole SAN failures. ASM also provides evenly distributed I/O across a diskgroup. Since ASM has a better picture of what's happening under the hood, Oracle can automatically provide a better balance of I/O to disk for you.
Challenges to ASM Adoption
ASM is certainly a powerful technology with a lot of potential. But with every technical solution, there come a whole host of other challenges. In the case of ASM, it potentially disrupts the usual balance of power between the Unix + Systems Administration groups, and the Database/DBA groups. Traditionally the former group manages disks, hardware, and the operating system level, leaving the DBAs to coordinate with them for new resources. This would change that balance somewhat, which could cause some resistance from that group.
In the end, it should be the business need that pushes this adoption. Also be aware that ASM is still in the enterprise computing sense, relatively new. There are a number of vendors whose core business has been in the logical volume manager/filesystem space for years. Quite often, maturity matters a lot when it comes to software systems, and reliability.
ASM is powerful stuff, providing solutions for the growing very large database systems being deployed currently. It may also provide solutions for smaller database installations, or those using clustering. As with any new technology, evaluate, test, and then test some more.
» See All Articles by Columnist Sean Hull