Re[2]: sybase database & expiry
1998-02-13 16:01:09
Subject: |
Re[2]: sybase database & expiry |
From: |
ALLEN BARTH <abarth AT KEMPER DOT COM> |
Date: |
Fri, 13 Feb 1998 15:01:09 -0600 |
SQL Backtrack has a control file where you specifiy the number of
version to keep. Each and every 'object' presented to ADSM from
Backtrack has a date/time stamp on it, and as far as ADSM is
concerned, these are unique objects. As such ADSM won't version them
off. It is the Backtrack api interface that is specifically telling
ADSM what to delete.
I still have several objects in ADSM that came from Backtrack. The
problem being that Backtrack doesn't know about them anymore, so they
won't go away.
Since there is no specific way to tell ADSM to forget all about an
object it has in it's database, the only way to get rid of them would
be to delete the 'filespace' which contains ALL the Backtrack backups.
NOT QUITE RIGHT!
BTW, these objects were created over a year ago under 2.1.0.3 or lower
client and I don't remember what version of Backtrack. We haven't
seen any more occurances of this with the latest Backtrack with
2.1.0.6 client.
Regards,
Al
______________________________ Reply Separator _________________________________
Subject: Re: sybase database & expiry
Author: Naomi van Roosmalen <nvanroosmal AT NBTEL.NB DOT CA> at ~Internet
Date: 2/13/98 3:14 PM
Hello,
Thank you for your response. Does this mean that that data
can never be deleted? I know ADSM version 2 only allows for
deletion of entire filespaces which is not what I want. Does
SQL backtrack allow for deletion of files?
Naomi van Roosmalen
gmangum AT umich DOT edu wrote:
>
> SQL Backtrack generates a name for each backup copy which contains
> the date/time of the backup, so you never have extra copies as far
> as ADSM is concerned. Each backup from SQL Backtrack to ADSM is
> considered by ADSM to be a new file.
>
> --
> Gene Mangum
> University of Michigan Medical Center
|
|
|