Message authorized by:
: [email protected]_at_internet at X400POST
------ =_WT25080.363f9d55.0a0/mta.mcdermott.com
Inside Backtrack, you tell the software how many versions to keep.
Inside Backtrack, you tell the software how many versions to keep.
This info is stored in either *.physical or *.logical, depending on
the backup type you are using. There is a directory for each Oracle
server in that top directory and a file with each database name in the
server directory. You can browse the file and notice what you have
set for the number of versions. If this is large, you probably set
unlimited and you all the backups you ever did listed in these files.
You should be able to edit the file, and the next time you run your
backups, it will send the appropriate delete file command to ADSM
which will remove the entry from you database the next time you expire
inventory.
My problem is that if a database is large, Backtrack creates a
.0,.1,.2, and so on. The delete command only takes care of the .0 and
the others are left out there with Backtrack not knowing about them,
ADSM not showing them in the filespace, and no way to remove them
except to delete filespace and remove all entries for Backtrack (at
least that is what I have done so far). I hope this is helpful. I
will be opening a ticket tomorrow with Backtrack support to resolve
this issue and suggestions on how to Archive into ADSM instead of just
hitting the backuppool.
______________________________ Reply Separator
_________________________________
Subject: SQL*Backtrack object deletion
Author: [email protected]_at_internet at X400POST
Date: 11/3/98 4:42 PM
I've been talking to some of our Oracle DBA's, and we have discovered
that we have a problem.
We've been using SQL*Backtrack with Oracle for about the last 9 months
during the commissioning of a complex system for UK Electricity
deregulation. What we now have is a primary storage pool which is about
100 3575 tapes (about 1.5TB) of largely useless test data, together with
two offsite copy pools of about the same size.
Unfortunately, what we have found is that SQL*Backtrack names each table
backup with a constructed name that includes the date that the backup
was taken. This means that each backed up entity has a unique name, and
therefore that normal versioning does not kick in. As we keep the last
version of a file forever, this means that nothing is ever deleted.
Due to a tremendous lack of foresight, we are using the same management
class as our normal dsmc incrementals for said machines. This means that
I cannot just turn on ageing of the data without affecting the other
backups that we have.
Again, with more thought, I would probably have deleted or renamed the
filespaces that were created before we went live with the systems.
I also have a problem in that query filespace on the filespaces that
SQL*Backup has created shows the filespace but shows the amount of data
backed up as 0.0K. Now this could either be because the data is too
large, or that the normal tools cannot handle SQL*Backup filespaces. I
think that the latter is the case, as I cannot see the contents of the
filespace using dsmc on the client, even if I use the correct tag. I
know that there is data, because a query content on tapes selected at
random shows entities (I shall refrain from calling them files) in the
SQL*Backtrack filespace.
My DBA colleagues do not appear to be able to see a way of deleting the
table backups in SQL*Backtrack (nor even referencing them if we have
lost the profiles!).
Now, the challenge is to delete some of the useless data (almost all
SQL*Backtrack backups until about a week ago) without affecting any of
the other backups. There does not appear to be a way in SQL*Backtrack,
and I have missed the window of opportunity to do it using filespaces.
Anybody any ideas? My server is on AIX 4.2.1, and is at 2.1.5.18. The
client code is on AIX and Digital Unix, and is 2.1.0.8 (I think on all
platforms), and we are using version 2 of SQL*Backtrack.
Any help gratefully received.
Peter Gathercole
Peter.Gathercole AT virgin DOT net
------ =_WT25080.363f9d55.0a0/mta.mcdermott.com--
=========================================================================
|
