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