And like Michael implied, running a select from the BACKUPS table on a production server is liable to kill its performance for a good while.
-------------------- Lindsay Morris CEO, TSMworks Tel. 1-859-539-9900 lind...@tsmworks.com On Tue, Apr 13, 2010 at 12:45 PM, John D. Schneider < john.schnei...@computercoachingcommunity.com> wrote: > Well, I am no expert on this, so I am willing to be corrected by > somebody if I don't have this right, but here is my understanding. > > Yes the deactivate_date will tell you when a given backup object became > inactive, but that won't reliably tell you when it will expire, because > as I said, you don't know what other versions will be coming along. > Newer versions can cause it to expire sooner. > > What if, in my previous example, yoda.txt is in a management class whose > backup copygroup policy is 7 versions for 30 days? The file gets backed > up on 4/13/2010. The next day yoda.txt changes, so it gets backed up > again on 4/14/2010. So at the next 'expire inventory' the 4/13/2010 > version of the file becomes inactive, and deactivate_date gets set to > 4/13/2010. If the policy says 30 days, it would be easy to think, yeah, > it is going to really expire on 5/13/2010, 30 days later. But what if > yoda.txt keeps changing every day? Then yoda.txt from 4/13/2010 is going > to expire when 7 new versions have backed up, on 4/20/1010. But what if > yoda.txt only changes every other day, or not at all? > > You can do a select to find out all the files that are deactivated, but > the best you could determine is the outside window of how many days they > might still be around, based on the number of days in the policy. But I > am still not sure why it is useful to run such a report? > > Best Regards, > > John D. Schneider > The Computer Coaching Community, LLC > Office: (314) 635-5424 / Toll Free: (866) 796-9226 > Cell: (314) 750-8721 > > > > -------- Original Message -------- > Subject: Re: [ADSM-L] Running a report on what files will expire in the > next sixty days > From: Michael Green <mishagr...@gmail.com> > Date: Tue, April 13, 2010 11:19 am > To: ADSM-L@VM.MARIST.EDU > > John, > > Please correct me if I'm wrong. > select * from syscat.columns where tabname='BACKUPS' > shows that there is a column called DEACTIVATE_DATE. I guess if you > write a select statement crafted in such a way that it also takes into > account current date, the management class (CLASS_NAME from BACKUPS) > VERE/VERD/RETE/RETO, then you can conclude if the object is candidate > for expiration. > > Running such a select on a production machine is a whole other story. > -- > Warm regards, > Michael Green > > > > On Tue, Apr 13, 2010 at 6:37 PM, John D. Schneider > <john.schnei...@computercoachingcommunity.com> wrote: > > Because of TSM's incremental backup scheme, there is no way to know what > > files will expire, because their is no way to know what new versions of > > files will be taking their place in the future. For example, say there > > is a file called yoda.txt. If that yoda.txt file is backed up once and > > is never changed, then the backup for it will never expire because the > > backup of that file remains the "active" version of that file. If, > > however, yoda.txt is changed from time to time, and a backup runs every > > day, then the older versions of the file become "inactive" versions of > > the file. Then the inactive versions will expire when they exceed > > either the number of days or versions that you defined in the policy. > > > > So, when I backup yoda.txt today, there is no way to know when this > > version of yoda.txt is going to expire, unless I have some way to know > > how many new versions are going to replace it in the future. > > > > Can you tell us why you think it is necessary to predict what files will > > be expired, or when? Since new backup data will be coming in > > continuously, is it really important to know? > > > > Best Regards, > > > > John D. Schneider > > The Computer Coaching Community, LLC > > Office: (314) 635-5424 / Toll Free: (866) 796-9226 > > Cell: (314) 750-8721 > > > > > > > > -------- Original Message -------- > > Subject: [ADSM-L] Running a report on what files will expire in the > > next sixty days > > From: yoda woya <yodaw...@gmail.com> > > Date: Tue, April 13, 2010 9:37 am > > To: ADSM-L@VM.MARIST.EDU > > > > Is there a way to find the list of files/amount of data that will expire > > in > > the next 60 days? > > >