Re: ASM - hardware mirroring vs. Oracle mirroring

  • From: "Greg Rahn" <greg@xxxxxxxxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Wed, 16 Apr 2008 14:37:14 -0700

>
> ASM's main purpose is to provide striping and mirroring, is it not?
>

ASM stripes all datafiles in an ASM disk group across all LUNs in that
diskgroup.  This makes it virtually impossible to not have perfectly
balanced IOs across the LUNS.

Take a simple example of a host that sees 4 equally sized LUNS.  If
you were to use a cooked filesystem on those LUNS you would need to
create 4 datafiles for each tablespace to achieve the same thing that
ASM could do.  Using ASM will reduce the number of files and thus the
number of file descriptors that is required because now 1 single data
file will be striped via ASM over all 4 LUNS.  Also if the tablespace
did not start out with 4 datafiles (so most recent data is in the 4th
file) ASM will balance even that file.

Now consider a host that has 100 LUNs.  It becomes much easier to
manage and balance the datafile IO with ASM and to keep it uniform.

One reason to stay with storage level mirroring (or external
redundancy in ASM terms) is that it reduces the number of host IOs.
When ASM does the mirroring (normal redundancy) two host IOs are
required (in parallel), one for the primary ASM extent and one for the
mirror.  If you are using high redundancy then it would be 3 parallel
IOs.  This, and usually storage array rebuilds are much faster than
host level rebuilds when there is a failure.

>
> If you already are using a storage subsystem that performs those tasks, what
> is the added benefit of ASM?
>

Besides having a perfectly balanced IO load, one of the largest
benefits of ASM is the ability to online rebalance.  If you were to
add storage to a cooked file system you would have to manually move
datafiles to the new filesystem to make it evenly balanced.

>
> Does that benefit exceed the drawbacks?
>

The only drawback I see with ASM is that storage admins can become territorial.

Technically I really don't see any drawbacks with ASM.  I've been
using ASM for every benchmark since 10gR1 was released in 2004.  I
used to spend a week with a storage admin working out
disk/LUN/datafile layouts.  Now I spend less than a day with ASM.  I
just ask for the best performing LUN configuration and put them all
into ASM.  Doesn't matter if I have one tablespace or 100 or if a
tablespace has one datafile or 100, they are all equally balanced
across all the LUNs.  Doing this by hand was a pain and time
consuming.

>
> to Jared's point, doesn't it seem inevitable that use of ASM will shift
> storage responsibility from storage and/or system admins to the DBA?
>

I don't think it shifts any responsibility other than perhaps who is
monitoring how full the disks get.  If you are using RAW, then it's
really no different.

It may not be as clear how much simpler ASM makes things at the small
scales (<1 TB), but when your database is 2 TB, 5 TB, 10 TB, 25 TB or
75 TB, and you are dealing with 5, 10, 15, 20 arrays, I think you will
quickly start to see the difference.

-- 
Regards,

Greg Rahn
http://structureddata.org
--
//www.freelists.org/webpage/oracle-l


Other related posts: