Hi, Debbie, Tab. You'll have to rebind those objects. Since they're inactive, it'll be really fun. In fact, it's probably not worth doing all the steps in Option 2 if you have a lot of objects, but it's a fun exercise anyway.
Option 1) This is the easiest if you're a C programmer. Use the TSM API and some custom C code. I haven't tried this, but I don't recall reading anything that says the dsmUpdateObj call has to be used against an active object. The API manual says: "You can also rebind backup copies to a different management class by using the dsmUpdateObj call and the DSM_BACKUPD_MC action." Option 2) Let's say /FSNAME is the filespace name of the inactive object, and OBJECT is the object name. First you create a management class with RETEXTRA and RETONLY of 0, or use an existing one with a short enough retention for your requirements. You create the filesystem /FSNAME. You create a small file in /FSNAME called OBJECT. You back it up using the baclient and bind it to the management class you created. It'll rebind both the file and your inactive database objects with the same HL_NAME and LL_NAME. Then you delete OBJECT from the /FSNAME filesystem, then dsmc inc /FSNAME/OBJECT again, or use the expire command. It'll expire it, then during your next expiration process it'll go away. What gets fun is in Windows, like Tab's problem. You actually have to create a new drive, say, \\servername\q$. Then you create your OBJECT file path and whatnot under there, then on the TSM server do a "rename filesystem" to go from \\servername\f$ to \\servername\q$. Then do your backups, rebinding, and delete/expire, then rename the filesystem back. As I said, it's a lot of fun. Gotchas to watch out for are the possibility of inactivating all your good stuff if you just dsmc inc /FSNAME, or rebinding stuff you don't want rebound. You might want to test first. :-) I've actually used this process to get rid of a few DB2 backups. It was a while ago, so I might be missing a few steps. And in Tab's case, he'll probably want to write a script to create all those directories, rebind, delete, etc. Good luck! Alex Paschal Freightliner, LLC (503) 745-6850 phone/vmail -----Original Message----- From: Weeks, Debbie [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 6:30 AM To: [EMAIL PROTECTED] Subject: Re: Delete obsolete directories only? 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:[EMAIL PROTECTED] On Behalf Of Steve Harris Sent: Monday, April 19, 2004 7:12 PM To: [EMAIL PROTECTED] 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 >>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED] On Behalf Of Tab Trepagnier Sent: Friday, April 16, 2004 1:47 PM To: [EMAIL PROTECTED] 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. ************************************************************************ ***********
