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