ADSM-L

Re: Expiration / deletion of inactive files do not appear to be working for SQL-BACKTRACK

2005-05-19 15:26:45
Subject: Re: Expiration / deletion of inactive files do not appear to be working for SQL-BACKTRACK
From: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 May 2005 15:26:18 -0400
> Hi:
> We've just discovered q peculiar problem with expiration involing the
> SQL-BACKTRACK product and SYBASE and ORACLE databases. They do not
> appear to be expiring.
>
> The managment class rules are:
>
> DOMAIN_NAME CLASS_NAME VEREXISTS VERDELETED RETEXTRA RETONLY DESTINATION
> SPAIX DBBKUP1 60 0 30 0 AIXDISKBACK
>
> And a "query backup /BACKTRACK:obackups.physical/*/* -inactive" returns
> a HUGE list of files that are inactive.
> They should all have been deleted with the RETONLY set to 0.
>
> Am I missing something?

The -inactive option causes the query to list inactive files as well as
active files, not inactive files instead of active files. In the query
output line below, the 'A' after 'DBBKUP1' indicates that the file is
active. The rest of the query output lines in your original message
also showed active files. It is not clear that you have any inactive
backups of Oracle and Sybase data.

When our site had problems with SQL/BackTrack (we has since switched to
TDP), the most frequent cause was forgetting to specify 'backdelete=yes'
when registering nodes.

> A DB called SQL-BACKTRACK support and the responce was SQL-BACKTRACK
> marked them inactive; at that point TSM
> is not correctly removing them per the definitions.
>
> Flat files in other management groups are behaving correctly.....
>
>
> API  5,242,880  B  10/15/03   02:54:53    DBBKUP1     A
> /BACKTRACK:obackups.phy
> sical/BRSSBKUP/controlfiles-0.15-10-2003.02:55:41-21544