When the migrations run, it actually works a little different than
most people expect, and you never really notice it unless you have a TSM
server being dominated by a few VERY large hosts.

        This is the way I see migrations working:

1. Looks at the high threshhold, has it been reached?
2. If it has, look at the migproc number ( say it's set to 5).
3. Which client has the most data in the stgpool to be migrated?
4. Start a migration process for that client's data.
5. Which client has the 2nd largest amount of data?
6. Start a migration process for that client' data.
7. etc. etc. until the 5 migration processes are started OR all the client's
with data in the stgpool have a migration started for their data.

        In the case were you only have 1 client very large client on a TSM
server (as in our case with a very big VMS cluster with many TB of data),
the above process gets to #5, sees there is no other clients with data in
the diskpool and stops spawning off processes.

        So, the dilemma we are discussing is that you only get one migration
process running to one tape, when you may have many processes on the client
shoving data into the diskpool faster than it can be siphoned off with one
tape drive.

        There are other ways to correct this behavior. Here, we have
discussed like using a 'virtualnode' scheme so it would backup different
types of disks under different node names and then be able to start multiple
migrations, but that makes a more manual restore process and would be more
difficult to maintain.

        We have just lived with the migration problem, but this may be a
solution to improve performance.

Ben Bullock
Unix system manager
Micron Technology Inc.


> -----Original Message-----
> From: William Boyer [mailto:wboyer AT PTD DOT NET]
> Sent: Wednesday, March 21, 2001 9: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/
> > >
> >
>