ADSM-L

Re: Speeding up my SQL statement

2004-06-29 08:52:21
Subject: Re: Speeding up my SQL statement
From: "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Jun 2004 14:52:40 +0200
Hi Richard!
> Sometimes, the best thing to do is perform Query Backup from the client
side,
where dedicated logic gets results faster.  It is often possible to
accomplish
that by masquerading as each defined TSM node, via VIRTUALNodename.

True, but since the Oracle backups are made through the TDP client, a Q
BACKUP from a BA client will return zilch...

> Another approach to finding flotsam, of course, is to inspect the last
backup
time in filespaces, which helps narrow down the search arena.

Also true (and an implemented approach here) but that will only show you if
the backup is working. I'm trying to narrow things down to the database
backup level. I want to see if there are obsolete backup pieces or if Oracle
delete jobs are running fine. A quick scan showed a lot of backup pieces
dating back to February for a specific node. I bet I have to contact the
database guys for this and my guess is that the Oracle delete jobs are not
running on this machine... Wouldn't be the first time...
Thank you very much for your reply!
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: Tuesday, June 29, 2004 14:03
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Speeding up my SQL statement


>I thought about that, but would that help? If TSM still has to scan every
>object for a match, it wouldn't help much... That's the problem, I don't
know
>how SQL works...

Eric - Your perception is correct: if you scan a table, it will traverse the
       whole thing.  Whereas the Backups table is the predominant (=huge)
table in a TSM system, it will take a long time.  Some optimization can be
had through well-formulated queries, but the opportunities for doing that
are
rather rare.  The only thing that really helps SQL performance is indexing,
where short, key columns are also kept in a hash.  Whereas TSM SQL is an
overlay on a B-tree database, I don't believe there is any indexing
opportunity, and so SQL scans are painful.

Sometimes, the best thing to do is perform Query Backup from the client
side,
where dedicated logic gets results faster.  It is often possible to
accomplish
that by masquerading as each defined TSM node, via VIRTUALNodename.
Another approach to finding flotsam, of course, is to inspect the last
backup
time in filespaces, which helps narrow down the search arena.

   Richard Sims


**********************************************************************
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.
**********************************************************************

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