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:[EMAIL PROTECTED]] > Sent: Thursday, August 29, 2002 2:36 PM > To: [EMAIL PROTECTED] > 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 > ========================================================================== > =====
