Re: ASM - hardware mirroring vs. Oracle mirroring

From: Greg Rahn <greg_at_structureddata.org>
Date: Wed, 16 Apr 2008 14:37:14 -0700
Message-ID: <a9c093440804161437y33f3b539qaa2fd3480442c317@mail.gmail.com>


>
> 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
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Apr 16 2008 - 16:37:14 CDT

Original text of this message