Last year at the SHARE in Minneapolis, there was a session on the Introduction
to the TSM DB.  Wa y too short and way too shallow, but the underlying
structure is a BTree.  The TSM "Select" statement seems to generate a pseudo
relational table in the DB free space.  That's why if your DB is too full and
your select casts a very broad net, you get hte insufficient space message from
TSM.  I have the handout from the SHARE sessions in my office and can give the
session number to anyone who's interested during the week.


Quoting Remco Post <r.post AT SARA DOT NL>:

> 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,
>
> 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
>


Fred Johanson