Hi Andy,
Below is a response that I am thinking about sending to a LISTSERV user.
Can you tell me if I am on track, or if you know the answer could you
share that information with me? thanks.
*****************************************************
Eric,
I am not sure that there is any better way to do your query than what you
have already done. You might want to try breaking your queries up into
smaller search patterns by maybe querying all nodes that begin with the
letter "A" then "B" and so forth and then run these scripts over the
course of serveral days to minimize impact on the server. Having said
that, I do not know what the side effect of this kind of query - in other
words, will the TSM Server query for all high level "//" and then filter
out the results based on node names or will it filter on node names first.
This is where you may want to try it on your test machine first.
Regards,
Neil Rasmussen
Software Development
Data Protection for Oracle
"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/04/2004 06:28 AM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
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
-----Original Message-----
From: Neil Rasmussen [mailto:rasmussn AT US.IBM DOT COM]
Sent: Tuesday, February 03, 2004 17:16
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Strange oprphaned objects
Eric,
Those look like Data Protection for Oracle backups.
Regards,
Neil Rasmussen
Software Development
Data Protection for Oracle
rasmussn AT us.ibm DOT com
"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/03/2004 08:11 AM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Strange oprphaned objects
Hi *SM-ers!
I have a Sun Solaris node for which I found something very strange. I
issued
a select * from backups where node_name='NODE' and I forwarded the output
to
a file. In that file I see some very old backup files which have a very
strange path. The filespace name for such a file is /data0001, the ll_name
is // and the object name is MT01D_t382461362_S3_P1.
The files cannot be seen by the BA GUI, because it only displays the files
located in /data0001/, not the files located in /data0001//.
Has anybody seen this before?
Client level is 4.2.3, server level is 5.1.8.
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.
**********************************************************************
|
