Peter,
2 options I can see:
create new (empty) files with names that match the files you want to
delete from ADSM. The old file will then become the 2nd version &
depending on your policy will probably get expired. Now you will just
be left with a lot of empty files on ADSM which won't consume any
space. Also I think if you bind this to a new mgmt class then you can
clear them out separately.
shorten your retain only version parameter to match when you when
live, so at least all the pre going live data will be flushed.
Cheers,
Simon
----------
| From: ADSM-L AT VM.MARIST DOT EDU; peter.gathercole AT VIRGIN DOT NET
| From: ADSM-L AT VM.MARIST DOT EDU; peter.gathercole AT VIRGIN DOT NET
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: SQL*Backtrack object deletion
| Date: Wednesday, 04 November, 1998 6:50AM
|
| 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
|
|
