ADSM-L

Re: [ADSM-L] Running a report on what files will expire in the next sixty days

2010-04-13 15:03:41
Subject: Re: [ADSM-L] Running a report on what files will expire in the next sixty days
From: Lindsay Morris <lindsay AT TSMWORKS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 13 Apr 2010 14:02:46 -0400
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
lindsay AT tsmworks DOT com


On Tue, Apr 13, 2010 at 12:45 PM, John D. Schneider <
john.schneider AT computercoachingcommunity DOT 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 <mishagreen AT GMAIL DOT COM>
> Date: Tue, April 13, 2010 11:19 am
> To: ADSM-L AT VM.MARIST DOT 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.schneider AT computercoachingcommunity DOT 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 <yodawoya AT GMAIL DOT COM>
> > Date: Tue, April 13, 2010 9:37 am
> > To: ADSM-L AT VM.MARIST DOT EDU
> >
> > Is there a way to find the list of files/amount of data that will expire
> > in
> > the next 60 days?
> >
>