You have to either make sure no one is pushing backup/archives to the disks
or do the old
vary offline xxx
upd vol xxx acc=reado
vary online xxx
move data xxx stg=blahtape
upd vol xxx acc=readw (you can do this while the move is running 'cause the
move data has it locked to writes)
Otherwise your inbound clients will blow off if you just do a move data...
the process will lock the disk and clients fail with no space available on
server (or something like that) but the above process does this all cleanly
(if you don't know about current client activity on the box)
Dwight
-----Original Message-----
From: bbullock [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 9:38 AM
To: [EMAIL PROTECTED]
Subject: Re: SAP and 3494 performance.
Hmmm, an inventive way to get a large client to multi-thread the
migration to tape. Thanks for the idea, I'll have to look into writing a
script myself to do it on one of my TSM servers.
Thanks,
Ben Bullock
Unix system manager
Micron Technology Inc.
> -----Original Message-----
> From: Davidson, Becky [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 7:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SAP and 3494 performance.
>
>
> We ran into the same issue on the migration so our solution was do two
> things. Our backups start at 4pm. I let them run until
> about 8pm and then
> I lower the migration threshold. At 10pm (backups finish
> around 10 or 11) I
> kick off a script that makes a list of all of my disk
> volumes, divides it
> into 4 scripts and then does move data's to my tape pool.
> This gives me 5
> sessions draining the disk pool and it generally finishes
> about 2am at which
> point I kick in my backup to copy pools. This kept us going
> to disk so we
> can increase the number of threads yet let us drain in a
> timely fashion.
>
> -----Original Message-----
> From: Cook, Dwight E [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 1:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SAP and 3494 performance.
>
>
> Our client is a Sun E10K with ?24 processors? maybe more if that is
> possible... it has a bunch
> And we have other AIX & SUN...
>
> Tsm server is an S70 and runs less than 30% cpu util during
> the backups...
>
> Here is the poop on multiplexing...(check in your TDP for
> SAPR3 manual)
> mainly if you are going straight to tape 'cause each session
> will require a
> tape drive.
> By going to a diskpool, you aren't limited by the number of
> tape drives you
> have...
> BUT remember there will only be a single migration process
> for a single
> client's data within a diskpool no matter what your migration
> process limit
> is or how many tape drives you have... and a single migration going to
> 3590B1A (what I see) averages out to be just over 20 GB/hr...
> so I can load
> up my diskpool with 600 GB at 41 GB/hr but can only empty it
> at 20 GB/hr
> :-(
> I'm looking into having the client use two management
> classes, direct it to
> two different diskpools (say 10 processes dumping into each
> diskpool) then
> their total rate into the tsm server will be 41 GB/hr, the
> limit of the fast
> ethernet card, AND I'll be able to bleed the data off to tape
> at 40 GB/hr (a
> migration process for each diskpool with each migration
> process moving 20
> GB/hr) Now maybe if I'd upgrade the B1A's to E1A's I could
> get about 35
> GB/hr average on the migration but I don't know...
> Anyway, also if one of your multiplexed files goes bad then you have
> multiple .dbf files bad and makes a recovery a little
> harder... just the
> way we do it.
>
> Dwight
>
> -----Original Message-----
> From: Richard L. Rhodes [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 7:23 AM
> To: Cook, Dwight E; [EMAIL PROTECTED]
> Subject: Re: SAP and 3494 performance.
>
>
> Thanks for great info!
>
> q) What kind of a client system are you using?
> - machine type
> - # of processors
>
> q) When you say "> don't multiplex with tdp" I'm not sure what you
> mean.
> - Are you using TDP for SAP?
> - Why Not?
>
> Thanks!
>
> Rick
>
>
> On 20 Mar 2001, at 10:59, Cook, Dwight E wrote:
>
> > alter to go to diskpool first
> > use tsm client compression
> > don't multiplex with tdp
> > run about 10-20 concurrent client sessions (based on
> processor ability)
> > you should see about 4/1 compression
> > you should see about 11.6 MB/sec data transfer (if things
> are really OK &
> > processor can keep up)
> > you should see your db backup in just over 2 hours...
> >
> > we have a 2.4 TB data base, use the above methods and push
> 600 GB (the
> > compressed size) in 16 hours...
> > we also have smaller ones we see the same rates with...
> such as a 200 GB
> > that compresses down to about 60 GB and runs in under 2 hours
> >
> > hope this helps...
> > Dwight
> >
> >
> > -----Original Message-----
> > From: Francisco Molero [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 20, 2001 9:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: SAP and 3494 performance.
> >
> >
> > Hello,
> > I have a query about performance between a TDP for SAP
> > R/3 under HP-UX and TSM Server with a 3494 library.
> > The size of database is 350 GB and the connection is
> > via tcpip (ethernet 100). I used the brbackup -c -t
> > offline command and the bacukp is sent to tape pool in
> > the library 3494. I have a private network and also I
> > am using the compression parameter to yes in the
> > client in order to improve the performance in the
> > network. The backup takes 6 hours in backing up the db
> > and this time is very high. I need to reduce it. the
> > drives are 3590, and the format device class is DRIVE.
> > Can someone help me about the parameters which can
> > improve this performance ???
> >
> > Regards,
> > Fran
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
> >
>
