ADSM-L

Re: SAP and 3494 performance.

2001-03-21 13:17:47
Subject: Re: SAP and 3494 performance.
From: Joe Faracchio <brother AT SOCRATES.BERKELEY DOT EDU>
Date: Wed, 21 Mar 2001 10:18:23 -0800
Is this 1 client per mig process true if you're using collocate=filespace
instead of collocate=yes???  (and, of course, you bothered to get
filespaces on seperate volumes)????

            .,.. joe.f.

Joseph A Faracchio,  Systems Programmer, UC Berkeley


On Wed, 21 Mar 2001, Davidson, Becky wrote:

> We have only one client writing to the disk pool thus no matter what you set
> the migprocess at only 1 thread will run.  That is why we are running the
> move data
>
> -----Original Message-----
> From: William Boyer [mailto:wboyer AT PTD DOT NET]
> Sent: Wednesday, March 21, 2001 10:26 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: SAP and 3494 performance.
>
>
> Why not just set the MIGPROCESS=5 when you lower the migration threshold? Do
> yo find the MOVE DATA more effecient than the MIGRATION processes?
>
> Bill Boyer
> DSS, Inc.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> bbullock
> Sent: Wednesday, March 21, 2001 10:38 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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: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/
> > >
> >
>
<Prev in Thread] Current Thread [Next in Thread>