Re: ASM - hardware mirroring vs. Oracle mirroring

Greg,

It seems you make so many assumptions that in almost all client sites I've been to are wrong in your reply. For example if you get 4 equally sized LUNS from a SAN, usually they would already be striped and mirrored in the array. If they're not, perhaps you're using a volume manager like Veritas which can then both stripe and mirror for you. Thus you wouldn't have 4 different filesystems that you had to put 4 datafiles per tablespace in, but just one large filesystem.

You can do the same with a 100 LUNs, and by the way, good luck having 100 LUNs in ASM and then try adding 10 more. The rebalancing will kill you. That discussion has been on this list before. The same goes for your 75TB database. Try adding 25TB to the 75TB disk group and see how long the rebalance will take.

I'm not against ASM. It has its place (When using RAC for example. Especially on Linux). But IMHO it's not the end-all-be-all solution either.

Finn

On Wed, Apr 16, 2008 at 4:37 PM, Greg Rahn <greg_at_structureddata.org> wrote:

> >
> > 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
>
>
>

--
http://www.freelists.org/webpage/oracle-l