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:Becky.Davidson AT EGR DOT COM]
> Sent: Wednesday, March 21, 2001 7:23 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:cookde AT BP DOT COM]
> Sent: Tuesday, March 20, 2001 1:02 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:rhodesr AT firstenergycorp DOT com]
> Sent: Tuesday, March 20, 2001 7:23 AM
> To: Cook, Dwight E; ADSM-L AT VM.MARIST DOT EDU
> 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:fmolero AT YAHOO DOT COM]
> > Sent: Tuesday, March 20, 2001 9:35 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > 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/
> >
>