Re: ASM - hardware mirroring vs. Oracle mirroring

From: Finn Jorgensen <finn.oracledba_at_gmail.com>
Date: Tue, 22 Apr 2008 18:40:18 -0500
Message-ID: <74f79c6b0804221640i228c4b6cs6a5f58aa11560e7f@mail.gmail.com>


As Dan says dbms_file_transfer or RMAN are your options.

Finn

On Tue, Apr 22, 2008 at 1:42 PM, Dan Norris <dannorris_at_dannorris.com> wrote:

> Nope, not until 11g, but it doesn't work so well even in 11g according to
> Alex:
> http://www.pythian.com/blogs/910/oracle-asm-11g-does-the-asmcmd-cp-command-really-work
>
> You should look at DBMS_FILE_TRANSFER as a possible alternative, though.
>
> Dan
>
>
> Ram Raman wrote:
>
> Is there a command in asmcmd to copy files. Version 10.2.
>
> The command list seem to be limited to cd,du, find, help, ls,lsct, lsdg,
> mkalias, mkdir, pwd, rm, rmalias. I am looking to make a copy of a file
> during testing.
>
>
>
> On 4/16/08, Finn Jorgensen <finn.oracledba_at_gmail.com> wrote:
> >
> > 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
Received on Tue Apr 22 2008 - 18:40:18 CDT

Original text of this message