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/
>

Reply via email to