There is an unsupported program ADSMPIPE which uses ADSM API
I think the source code is on the net
With this tool you can first rebind the objects to a new mgmt class
with VER deleted=0
Expiration will delete them after.
I haven't use ADSMPIPE
Alain Ricois
____________________________ Séparateur Réponse ________________________________
Objet : Re: SQL*Backtrack object deletion
Auteur : "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> à Internet
Date : 04/11/98 08:45
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
|
--------------------------------------------------------------
Groupement d'Interet Economique IBESIS
Groupement d'Interet Economique IBESIS
4, Rue Doguereau
28100 DREUX
France
Tel : +33 (0) 2 37654700 - Fax : +33 (0) 2 37427436
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed.
If you have received this email in error please notify
postmaster AT ibesis DOT com"
--------------------------------------------------------------
=======================================================================
|
