Re: Obacktrack
1998-09-17 10:15:04
Bactrack has a control file which keeps track of the "file names" it
creates and the number of versions it keeps. If this file gets
corrupted then the backtrack interface won't be able to tell ADSM what
file to delete.
Each file created in ADSM by backtrack has date & time as part of the
filename, so to ADSM these are each unique files and won't ever go
away. You can:
a. delete the BACKTRACK file space for the node (a bit drastic)
b. modify/compile the sample api that comes with adsm (or did in V2
anyway, haven't looked since)
c. edit the backtrack control file and add entries for the files to be
deleted (had minor success with this)
Hope this helps,
Al Barth
Scudder Kemper Investments
______________________________ Reply Separator _________________________________
Subject: Obacktrack
Author: "Fluker; Tom R" <Tom.Fluker AT VIASYSTEMS DOT COM> at ~internet
Date: 9/17/98 9:28 AM
We're using the BMC/Datatools Obacktrack product to backup Oracle
databases... My problem is in convincing all of the Obacktrack/ADSM magic
to actually remove old versions of the backup data. The virtual files in
ADSM are created by Obacktrack using the API and it doesn't seem to be
deleting them....
BMC offered the suggestion of "setting RETAINONLY and/or VERDELETED to
zero". I tried setting VERDELETED to zero, expiring inventory, but (alas)
still have the same gigantic volume of data in the effected filespaces...
Does anyone have any suggestions or experience with this???
Thanks,
Tom Fluker
|
|
|