Ok I have a really puzzling question.  I have migdelay=1 also but when I
look at the percent utilized on my disk volumes it shows at 26.90% and
29.20% in each pool and during migration it drops to 6.10% and 7.60%.  now
if my diskpools are 30gb each and the amount of migration yesterday was at
54gb and when I did a select of the backups and came up with over 80gb.
someplace something isn't adding up.

any thoughts?

thanks
Paul

> -----Original Message-----
> From: Mark D. Rodriguez [SMTP:mark AT MDRCONSULT DOT COM]
> Sent: Thursday, August 29, 2002 2:36 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: migration -  when should it happen?
>
> Coviello, Paul wrote:
>
> >HI I have a 2 part question.
> >
> >        1.  we currently have a controlled migration that happens at
> 10:00
> >am everyday.  We have the following comand: update      stgp backuppool
> >highmig=1 lowmig=0 migproc=3.  We are getting complaints that the data
> >should stay on the disks the    whole day for restorations. I was
> thinking
> >about pushing it out to 4:30.  And then of course we have expiration and
> the
> >reclamations and the db backup.  So what should be the order of these?
> We
> >have 30gb for our backuppool.  which    leads to the second question.
> >        2. What command can I run to get the amount of data that was
> backed
> >up last night?  in case we want to set it to 50 or      something.  I
> just
> >want to be able to control this so it does not effect the backups at
> night.
> >
> >        thanks
> >        Paul
> >
> >        Paul J Coviello
> >        Sr Systems Analyst
> >        Catholic Medical Center
> >        2456 Brown Ave
> >        Manchester, NH 03103
> >        603 663-5326
> >
> >
> Hi Paul,
>
> I see you have gotten a couple of answers already, but I will add my 2
> cents worth anyway.  As far as your second question. Petur's select
> statement looks quite similar to the one I have written to do the same
> thing.  It's you first question that can be quite interesting.  First
> let me say that there is no single right answer to this question.  You
> must consider all things in your environment and then make a decision.
>
> One of the other response had mentioned turning on "cache=yes" for the
> diskpool.  I am not saying that is wrong or that it won't work, however
> you should realize that it will but a burden on the system during you
> backup window when clients are writing to the diskpool in addition it
> will increase the size of you TSM DB and TSM log usage.  What happens is
> that when a file is cached the DB keeps tracks 2 objects for the same
> file, one in the diskpool and one in the tapepool.  Eventually the
> diskpool becomes physically full.  When the next file arrives TSM saves
> that file which may cause one or more of the "cached" files to be
> dropped, therefore TSM has to to some extra DB transactions to remove
> the "cached" file references from the DB.  All of this is consuming cpu
> cycles and I/O bandwidth at the time when you need it the most.
> Therefore, unless performance is not an issue I do not use the
> "cache=yes" option for a diskpool.
>
> So here is what I generally do for my customers and why:
>
> 1) I size disk storage pools to hold 2.25 x the amount of nightly data
> transferred to the server disk pool.
> 2) I set "MIGDelay=1" so that I hold data on disk a minimum of 1 day.
> 3) I do my migrations after business hours, but before my backup window
> starts.
>
> The reasoning:
> 1) Having 2.25 x the normal daily data traffic in my diskpool allows me
> to hold 2 days worth of data and have a little head room for the
> unexpected.
> 2) The combination of 2 and 3 from above gives me the ability to restore
> from disk any thing that has changed in the last 2 days, i.e. all
> business day Wednesday my customers will be able to restore from disk
> anything that has changed since the Sunday night/Monday morning backup.
> 3) Another aspect is, since I do my "ba stg diskpool copypool" prior to
> migration all of my writes to copy pools are from disk to tape not tape
> to tape.  I still do a "ba stg tapepool copypool" just in case something
> fell thru the cracks, but this normally runs instantly with no data
> having to be moved.
>
> Proper scheduling can really make a difference in how well your TSM
> environment runs.  Since scheduling is so important you will also see
> people have a variety of opinions on how it should be done.  In fact I
> have seen people argue over scheduling like they were religious wars!
> The bottom line is you must look at the whole picture not just one
> aspect of it.  There are many things to consider besides what is the
> backup window for my clients.  You should also consider operator
> availability to load/unload tapes from the library, when to tapes
> physically get taken offsite, what are the frequency and size of your
> restores and many other factors as well.  One last thing to consider,
> always make sure that you have about 4 hours a day, preferably during
> normal hours, when you have nothing scheduled.  This is to allow you
> time to catch up in the event of some unforeseen problem that throws you
> off schedule.
>
> Sorry for the lengthy reply but I felt this was an important question
> that deserved a detailed answer.  I hope this will help you to make your
> decisions in a more informed manner.
>
> --
> Regards,
> Mark D. Rodriguez
> President MDR Consulting, Inc.
>
> ==========================================================================
> =====
> MDR Consulting
> The very best in Technical Training and Consulting.
> IBM Advanced Business Partner
> SAIR Linux and GNU Authorized Center for Education
> IBM Certified Advanced Technical Expert, CATE
> AIX Support and Performance Tuning, RS6000 SP, TSM/ADSM and Linux
> Red Hat Certified Engineer, RHCE
> ==========================================================================
> =====