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.
Getting Started
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
db_create_file_dest=+SEAN
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.
Conclusion
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
