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:Thomas.Rupp AT ILLWERKE DOT AT]
Sent: Wednesday, February 04, 2004 18:42
To: ADSM-L AT VM.MARIST DOT EDU
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:Eric-van.Loon AT KLM DOT COM]
Gesendet: Mittwoch, 04. Februar 2004 15:29
An: ADSM-L AT VM.MARIST DOT EDU
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.
**********************************************************************
|
