Hi Thomas! The problem is that these nodes all running old TDP versions and they cannot be upgraded easily. Anyway, TDPOSYNC wouldn't help me here either, because it only removes objects from TSM when there are no entries for those objects in the recovery catalog and for a lot of them there are! Our Oracle department is now checking the recovery catalog to see how many old backups there are. Thanks! Kindest regards, Eric van Loon KLM Royal Dutch Airlines
-----Original Message----- From: Thomas Rupp, Vorarlberger Illwerke AG [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 18:42 To: [EMAIL PROTECTED] Subject: AW: Strange orphaned objects Hi Eric, I recently had a similar problem. If you are on a recent TDPO version you can use TDPOSYNC utility to synchronise the RMAN catalog an TSM. But this will only help as long as the nodename/filespacename haven't changed. > The nodename was changed and also the Oracle filespace has changed. Do you know the "old" nodename/filespacename? If yes you could try dsmc query backup "/filespace_name/*" -SUBDIR=YES -virtualn=nodename That will give you the list of all saved Oracle files. API 16.413.696 KB 29.01.2004 22:11:33 DEFAULT A /DB22//full_DB22_s3039_t516751844_p1 API 16.413.696 KB 30.01.2004 22:11:17 DEFAULT A /DB22//full_DB22_s3057_t516838230_p1 If you are still saving to a filespace with orphaned files you can just rename the filespace and let TDPO create a new one. After the retention period (that means RMAN starts to delete old backups) you can just drop the old filespace on TSM. HTH Thomas Rupp -----Ursprüngliche Nachricht----- Von: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 04. Februar 2004 15:29 An: [EMAIL PROTECTED] Betreff: Re: Strange orphaned objects Hi Neil! My previous solution (del object) appeared to be a too easy solution. The old TDP backups are also present in the Oracle recovery catalog. Since then, a lot of things changed. The nodename was changed and also the Oracle filespace has changed. I guess it will not be all that easy to get rid of these backups, but it's worth trying because we talk about several gigabytes of obsolete data. What I now want to find out is if there are more of those nodes in my TSM environment. The only way I could think of is to create a select statement which lists all backups of non-oracle nodes with a ll_name of //. However, I ran that statement on my test environment and it took almost 3 hours to finish. On my production environment I'm afraid it will take days with all the negative impact on the database performance. Do you have an idea how to list these files without a select * from backups? Thank you VERY much for your reply in advance! Kindest regards, Eric van Loon KLM Royal Dutch Airlines ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
