Hi all!
I'd like to discriminate between two different tasks the TSM database
currently is used for:
First, there are TSM's "core" operations. Using another database instead of
TSM's "native" DB adds a lot of complexity to TSM. Some of the issues that
need to be considered are:
* interdependencies between product versions; maybe You cannot upgrade the
database because the TSM server You are using corrently does not work with
the new version; or You cannot upgrade the TSM server because You are still
waiting for the database release that is required (the guys in our
computing center have experienced many stories of this kind when it comes
to interoperability)
* which database products are supported; this adds a lot of complexity for
either TSM's development team (if they decide to support DB2 AND Oracle AND
...) or to the big customers who don't think TSM's internal database fits
their needs but that don't use (and thus don't have know-how with) the
database that TSM supports (as somebody in this thread already remarked,
this might even be a k.o. criterion for ADSM in some shops)
* what to do when disaster strikes and Your TSM (with a separate database)
server goes down; first, in addition to operating system and TSM server
software, You need to get the DBMS software installed and running (adding
time needed for disaster recovery); second, You cannot use TSM's standard
mechanisms (e.g. ADSM connect agent / TDP for ...) for backing up the
database, or else - when the database contents are lost - You have no means
to locate the tapes needed to recover the database itself; separate backup
mechanisms are needed to back up the database (at least for the TSM
relevant parts of it), and they need to be implemented for each operating
system / database combo supported
* (maybe there's more that I am not thinking currently)
So, for TSM's "core" tasks, I still think a highly specialized and
optimized TSM database is the way to go (at least as long as these topics
aren't adequately addressed). But ...
then there are the tasks involving reporting, problem determination, ...,
which clearly benefit from a flexible query tool. Surely, with ADSM V.3,
SQL queries to the ADSM database are supported, but my impression is that
the database isn't prepared to handle these queries well (when I started
playing around with SQL, I managed more than once to bring ADSM to its
knees by issuing rather simple queries).
These tasks, I think, would greatly benefit from a standard, general
purpose DBMS (with the added benefit that You may not query TSMs data
alone, but combine them with data from other sources); all that is needed
is a mechanism for replicating TSMs database into a foreign DBMS (and here,
I think, some parts of IBM's current product portfolio come in nicely: DB2
DataPropagator allows to replicate contents between DB2 databases, either
periodically or in "near realtime"; adding DB2 DataJoiner, You may
integrate other database systems, e.g. Oracle; the only missing part is
some kind of "TSM DataPropagator", which allows the TSM database to be a
source of data replication).
Sincerely Yours - Alfred Novacek
>I agree with Steve.
>
>The ADSM/TSM database structure is a pretty good transaction processor, and I
>commend the designers for that. There is quite a lot of time and manpower
>(person-power would be more PC, but I didn't think it'd get my point accross)
>invested in the current database by the developers, and it would be a pity to
>throw that out the window. But who says we have to do that. Let's discuss
>the possibility of a third party database as an option, similar to DRM being
>an option. This way, both camps are happy with their product.
>
>The current database also has some shortcomings. I think that the
>introduction of an SQL interface at Version 3 is an example of how
>non-standard the design really is. While we can now query some of the
>information using this method, I am suspicious that there is still a great
>deal more that is inaccessible. This would lead me to believe that the SQL
>interface was really just a 'kludge'. So I would hope the re-design of the
>database backend and incorporation of a commercial database might allow
>you to
>see the whole picture.
>
>Also, this might lead to the capability to add data to the database. I have
>been in a database corruption situation where we had to go back a week and
>do a
>point in time restore. We lost a full weeks worth of backups which were _on
>tape_ because we couldn't add records back into the ADSM database about
>that data.
>
>My suggestion is, don't cut this idea down without giving it some thought.
>It might not be useful in your environment, and that's fine, but if it
>increased performance by even 10%, I for one would be interested.
>
>-Matt
>
[...]
------------------------------------------------------------------------
Dipl.-Ing. Alfred Novacek
Dipl.-Ing. Alfred Novacek
Institute for Data Processing in Business Administrations,
Economics and Social Sciences
Johannes Kepler University Linz / Austria
E-Mail: Novacek AT idv.uni-linz.ac DOT at
Novacek AT pop.idv.uni-linz.ac DOT at
WWW: http://www.idv.uni-linz.ac.at
|
