RE: ASM or not to ASM
- From: "Storey, Robert (DCSO)" <RStorey@xxxxxxxxxxxxxxxxxx>
- To: <tim@xxxxxxxxx>, Oracle L <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 11 Jul 2011 12:41:45 -0500
Sorry, forgot to give you my system setup.
I'm moving from 9i 32bit to 11gr2 64 bit. Windows 2008 server.
My sysadmin has already carved out a huge chunk of disk space for me and
created my volumes.
My limited understanding of ASM was that (at least from a windows environment)
that you setup the physical disks, then created ASM. Once ASM was running, it
took care of where it would store data, where files would live, etc. As the
DBA you didn't deal with storage concerns other than balancing, and ensuring
that you had enough space for expansion.
________________________________
From: Tim Gorman [mailto:tim@xxxxxxxxx]
Sent: Mon 7/11/2011 11:55 AM
To: Storey, Robert (DCSO); Oracle L
Subject: Re: ASM or not to ASM
Robert,
My $0.02...
The main thing that is happening is that stuff which used to "belong" in the
realm of "root" and the Sys Admins are being moved under the realm of DBA. So,
there is a huge political aspect to the adoption of ASM that often overshadows
the technical aspect, and this political "shift of power" from Sys Admin to DBA
can be more of an obstruction than any other aspect of ASM adoption. Not sure
what things are like in your shop, but that is not a trivial concern.
It would be inaccurate to consider ASM to be "extra overhead". Along with that
shift of "power" from SysAdmin to DBA comes the shift in responsibility from
"root" to "oracle" accounts. If you are dealing with LUNs, volume managers,
and file-systems, then from a techical perspective using ASM is the exact
equivalent. You still have LUNs, but instead of a volume manager and a
file-system you have ASM. Very very similar, but running under "oracle"
instead of "root". So you can see that the big shift is human perception and
responsibilities amongst the humans -- the machine is still doing the same
things.
ASM is simpler to configure optimally for Oracle than all of the flavors of
file-system out there. Maybe you're already comfortable with that, maybe not?
Some folks constantly like to fiddle with FS block-size, with direct-I/O, wish
they could use asynch-I/O, etc. With ASM, its part of enchilada from the start.
Maybe you're using VxFS or some other file-system with licensing issues; this
is one area that Oracle actually saves you a few bucks.
Looking downstream, there are advantages with platform migration/rehosting that
come with ASM; not sure if that's slamming down the turnpike toward you.
Another big selling point with me personally is the ease by which database
files can be moved safely and without downtime from one SAN to another using
ASM; much easier than most other storage options. Run ALTER DISKGROUP ... ADD
DISK ..., ALTER DISKGROUP ... DROP DISK ..., then ALTER DISKGROUP ...
REBALANCE, and done.
It's tough to answer with detail without knowing present configuration, but
that's my seat-of-the-pants reaction to your question. If what you've got has
worked well so far, then stick with it, but if you reflect on things and
realize that you're trying to make the square peg of Oracle fit into the round
hole of file-systems, then ASM can make life easier and remove one more
variable to worry about from the whole performance optimization environment.
Hope this helps!
Thanks!
-Tim
-----Original Message-----
From: Storey, Robert (DCSO) [mailto:RStorey@xxxxxxxxxxxxxxxxxx]
Sent: Monday, July 11, 2011 10:30 AM
To: 'Oracle L'
Subject: ASM or not to ASM
Going through a 11gR2 new features class. First half day is all about
ASM and installing grid infrastructure for a standalone structure, My question
is why would I, on my single server with a single instance, using a SAN for my
storage, bother with ASM? Why do all of this overhead just for a single
instance? -- //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
