ADSM-L

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

2002-07-21 07:54:10
Subject: TSM DB design (was Re: TSM 5.1 Performance Tuning Guide - Where?)
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Sun, 21 Jul 2002 14:50:26 +0300
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.
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.
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.
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".
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.
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.
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.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: TSM 5.1 Performance Tuning Guide - Where?

Hi,

I cannot be convinced it is a relational database. Simple joins in select
statements take ages to complete, exactly the thing rdms-es are build to
do.
  TSM uses a b-tree to store its data. There is a world of possibilities
other
that rdbms or flat files. Tivoli has never stated exactly what db it is,
but
Kelly will be happy to tell you that it is best desribed as a relation
like
database. My guess is that an 'object database' is a better desription.
Google
will be your friend on finding out what an object database is (an no,
oracle
does not count as such, while it still has the word object added to what
they
do).

I will not fight your argument that there are multiple tables in the db,
and
that there are relations between those tables, but that does not make the
database a relational database. I can have a (hardcopy) cardfile with
relations
to another cardfile, does that make it a rdms? Not really, don't you
agree?
  What counts is what the db's internal structures are designed to do, in
TSM'
s case that is storing and retrieving objects refered to by some key, not
calculation relations between tables.

I'm very well aware that the select command has later been added to tsm,
or
at least later exposed to us. This was done to fill the need with some
admins
to do more complex queries that the standaard ones available. Unless
someone
from tivoli speaks up about this matter, I'll stick to what Kelly has told
me and the behaviour I see in TSM.

On zaterdag, juli 20, 2002, at 01:15 , Zlatko Krastev wrote:

> I hope you can be convinced TSM DB is pure relational and not flat files
> with few SQL queries on top of them:
> - Internal addressing of all data archived/backed up is through
OBJECT_ID.
> All links between the object (B/A client file, TDP backup/logs, Content
> Manager documents, etc.), the object's name and physical placement on
> volumes is through relations.
> - SELECT queries are not some kind of add-on but integral part of TSM
> server with very wide subset of DB2 features (field types, SQL
functions,
> etc.). If in doubt about any TSM SQL function look at its description in
> DB2 manuals.
> Have a look at nice post made by Roger Deschner on thread "tsm internal
> design?" 6 weeks ago. His definition for WDSF/ADSM/TSM is very nice and
> hits the bullseye. Thank you, Roger.
>
> Lets say TSM DB is not DB2 but a cousin of it. Actually they are derived
> from the same code. Also TSM DB physical layout is using same LVM code
AIX
> is using for filesystems and raw devices (but this is another story).
> If you are interested in the history of the product (and try to dig down
> IBM Announcement Letters archives) you can find TSM originate from
> mainframe world:
> 1. '80s - IBM Data Facility Storage Management Subsystem (DFSMS for
> System/370; still current and developed as DFSMS for S390/zSeries; very
> good product but mainframe guys can comment it better than me)
> 2. '91 - IBM Workstation Data Save Facility/VM (VM server to backup PCs
> running DOS)
> 3. '93 - IBM Data Facility Distributed Storage Manager (v1.0, from there
> come all dsm* names)
> 4. '93 - in version 1.1 renamed to IBM ADSTAR Distributed Storage
Manager
> (ADSM)
> 5. 1994-2002 - You probably know the rest.
>
> Same story for the DB2 - IBM had relational database (with SQL queries)
> for System/370; later ported to RS/6000, S/390, AS/400 (integrated in
the
> OS/400); got new name in '90s as DB2; later become DB2 UDB. Same
> research&concepts evolved from the old mainframes.
>
>
> 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