ADSM-L

Re: TSM DB design (was Re: TSM 5.1 Performance Tuning Guide - Where?)

2002-07-21 19:02:15
Subject: Re: TSM DB design (was Re: TSM 5.1 Performance Tuning Guide - Where?)
From: Remco Post <r.post AT SARA DOT NL>
Date: Mon, 22 Jul 2002 01:00:35 +0200
Hi,

On zondag, juli 21, 2002, at 01:50 , Zlatko Krastev/ACIT wrote:

I was nearly sure I will not convince you but the discussion is going and
everybody has different point of view and less facts can be omitted. My
knowledge is limited and I participate in this list just to learn more.

Same here :) Of course, like you, I've never seen any part of the TSM source
code, or found a developer of it who was able or willing to describe exaclty
the type of database underlying TSM. And we're all here to learn from eachother.

Not all joins take ages - the trick is to know not only the tables but
also the indexes and use them. On any rdbms without indexes the
performance is terrible. In DB2, Informix or Oracle we have the ability to
create new index to help our queries. Unfortunately in TSM we do not have
this ability and have to use only ones provided to us by Tivoli.

Very true. Still I'm convinced that even with myslq or postgersql or any other
relational database, a join of two tables each with less that 1000 entries
will be much faster that some of the joins in TSM. Of course I've never seen
a mysql database as large as 60 GB, like my TSM db....

I have some queries which improve their speed when you put additional
equations in where clause which leads to index use instead of exhaustive
search.

Hmm, intresting. Maybe we should build some documentation on what we have
found tot help, so everybody can profit from your and my knowledge. I've never
experimented with selects in that way.

I cannot agree with you, IMO object database is not close to TSM DB
design. Maybe it is time to compare what you mean and what I understand
when we say "relational database" and "object database".

IMHO (and I may go wrong here, since databases are not my speciality, though
they interst me a lot), a relational database is optimised for calculating
relations between two (or more) tables. An object database is not so much
optimized for calculating relations as much as retrieving and storing data
objects in its table structure. This does not mean that it cannot calculate
relations (it must be able to do so, even the simplest databasse is to some
extend relational) but it's table structures are not optimized to be able
to calculate those relations. In the case of a b-tree this may mean it has
to traverse a b-tree several times for one join, while an true relational
db would only have to traverse the table once.

OTOH I will not agreee with you also that two decks of cards cannot be
named relational database. In fact library catalogue is an implementation
of relational database ages before invention of computers.

You have a point there.

Unfortunately I am too young and my knowledge of of WDSF/VM is just
theoretical. I know it is predecessor of ADSM but never worked with it.

Neither have I. I've only been a system programmer for a few years now, fresh
out of school...

Also I cannot argue when select queries were implemented in ADSM. It might
be some cut functionality from original code which was brought back by
customer demand (as it might be added later). I do not know and cannot
comment.
On the end you are mentioning something "Kelly was told you". What is it?
Kelly who (Kelly Lipp?) ? Again I cannot understand what are you talking
about.

Kelly Lipp indeed. I had the pleasure of following his TSM level 2 course
earlier this year.

Unfortunately, we will never be able to figure out the thruth between ourselfs.
 That makes the discussion not less fun, but a bit less intresting. On the
other hand, is it truely important for us to know the details of TSM's 
internals?
 It's defenately nice to  know... But even if we knew, could we do anything
with that information? The only thing that might help is indeed building faster
select statements, that use either the index or table keys to find the needed
data faster... It's truely anoying to wait tens of minutes for a simple list
of tapes that are about to be reclaimed (as one example) or one of the many
other selects we have come up with (as TSM admins) and seem to perform poorly.

Zlatko Krastev
IT Consultant
---
Met vriendelijke groeten,
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer industry
didn't even foresee that the century was going to end." -- Douglas Adams