ADSM-L

Re: Delete obsolete directories only?

2004-04-20 09:30:46
Subject: Re: Delete obsolete directories only?
From: "Weeks, Debbie" <debbie AT ADMIN.USF DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 20 Apr 2004 09:29:59 -0400
Thanks Steve.  We have used the expire command, but this only seems to
mark them inactive.  Because the management class they are assigned to
holds the only version forever, or until it knows the file has been
deleted, they are marked inactive, but never go away.  Any suggestions
for completing the process and having them expire completely? 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steve Harris
Sent: Monday, April 19, 2004 7:12 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Delete obsolete directories only?

Debbie,

I'm not familiar with sql backtrack but...

I've used the normal BA client to delete orphan DB2 backups in the past.
These are archives and I used the delete archive command.  
If sql backtrack uses backups rather than archives, then take a look at
the ba client expire command

Because these are API backups, to address them from the BA client you
need to use a special syntax with braces around the "filespace" part of
the file name.  See the BA client doc for details.

Regards

Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia  

>>> debbie AT ADMIN.USF DOT EDU 20/04/2004 0:04:23 >>>
I have not seen a response to this question, and I have a similar
situation.  We had noticed that our filespaces for our Oracle DB backups
keep growing in leaps and bounds, and it finally became clear that they
were growing faster than would be expected in consideration of the
number of databases we have added.  Upon investigation I have found that
there is an enormous amount of space being used by backups that should
have expired, however I cannot delete the entire filespace because that
would also eliminate the valid backups.  

I have found that there seems to be two separate issues at play.  One is
that upon installing a new version of SQL Backtrack the Oracle admin
that handles those profiles used the wrong management class, leaving the
backups in limbo on TSM.  They have expired from the SQL Backtrack
catalog and marked inactive, however, they will never be removed from
TSM in their current state.  I cannot bind them to the appropriate
management class via the usual methods.  The other issue is that we seem
to have some stragglers from 2001 and 2002, that should have expired,
but are still hanging around for some reason.  

The only way I have found in the documentation to remove these items is
by deleting the object by object number from the database.  Can anyone
tell me if this is the only way to clean up these items, and if that
will in fact work to remove them from the tapepool storage? 

TSM for AIX 5.2.0
TSM for SUN/Solaris 4.2.1
SQL Backtrack 3.0, 4.0.10

Thanks,
Debbie


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Tab Trepagnier
Sent: Friday, April 16, 2004 1:47 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Delete obsolete directories only?

TSM Server 5.1.8.0 on AIX; TSM Client 5.1.6.0 on Windows 2000

I have a situation where over time, the location of data on our network
has moved from server to server.  In many cases we moved the identity of
the first server to the second server, but the data paths were not
duplicated exactly.  For example,

\\server_name\d$\current_root_path\...
\\*\*\old_root_path\...

where "current_root_path" and "old_root_path" are peers under the same
"d$" parent.

Because the "old_root_path" became invalid on the first backup of the
new server, all the data under it was marked inactive by TSM.  No
problem there.
Once the RetOnly duration elapsed, all the FILES were purged from that
path.  Again, no problem there.

But the directories were retained, probably because they were bound to
"no limit" permanent management classes prior to our implementing DIRMC
controls.  Meaning those directories will live for the duration of the
server's identity or our TSM system, whichever ends first.
Those duplicate paths confuse our Help Desk.  I would like to delete
just the contents under "old_root_path" since there are no files under
that path.  But because both root paths are under the same filespace, I
can't delete the filespace.  I turned on the permission "node can delete
backups" but that still didn't let me kill that directory tree.

So, is there a way to kill the directory tree under "old_root_path"
other than killing the entire filespace?

TIA

Tab Trepagnier
TSM Administrator
Laitram, L.L.C.



************************************************************************
***********
This email, including any attachments sent with it, is confidential and
for the sole use of the intended recipient(s).  This confidentiality is
not waived or lost, if you receive it and you are not the intended
recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of
this email is prohibited.  It may be subject to a statutory duty of
confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this
email in error, you are asked to immediately notify the sender by
telephone or by return email.  You should also delete this email and
destroy any hard copies produced.
************************************************************************
***********

<Prev in Thread] Current Thread [Next in Thread>