Re: ASM - hardware mirroring vs. Oracle mirroring
- From: "Ram Raman" <veeeraman@xxxxxxxxx>
- To: finn.oracledba@xxxxxxxxx
- Date: Tue, 22 Apr 2008 13:02:53 -0500
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
> 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
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> >
>
Other related posts:
