I also have to agree - and one of the big reasons is Matt's note about
falling back to a week-old ADSM database and loosing a week's backups.
Developers take note: I CAN'T DO THIS! Backups I can loose; archives MUST BE
KEPT. And my window for ADSM shutdowns is 12 hours long - once per week. If
the tools provided cannot recover/audit the database in this time period,
and I cannot recover the data from archives that have occurred since the
previous version of the database, then I need NEW tools.

And yes, I continue to look at solutions other than ADSM.

Tom Kauffman
NIBCO, Inc.

> -----Original Message-----
> From: Bacchi Matt VENDOR [SMTP:v2bacchi AT BTV.IBM DOT COM]
> Sent: Wednesday, November 17, 1999 6:26 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Using db2 or oracle or whatever for the TSM DB
>
> 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
>
>
>
> >Date:    Wed, 17 Nov 1999 09:46:12 +1000
> >From:    Steve Harris <steveh AT WESLEY.COM DOT AU>
> >Subject: Re: Using db2 or oracle or whatever for the TSM DB
> >MIME-Version: 1.0
> >Content-Type: text/plain; charset=us-ascii
> >
> >I on the other hand disagree!.
> >
> >The ADSM database does a good job of many of the things it needs to do,
> but as
> >always, I'm sure that it is being used in ways for which it was never
> designed
> >A good general purpose database will be able to cope with such changes
> better
> >than a purpose built one. Also, a general purpose database has
> appropriate
> >utilities to do many of the things that we are trying to do with our
> black box.
> >As an example, think how easy it would be to change platform types with a
> useful
> >unload/reload utility.  What about unreasonable limitations on database
> size
> >that exist with the black box?
> >
> >The problem as I see it is one that besets the whole of ADSM. There are
> some
> >users  (like me) who back up two servers of one kind and don't want
> unnecessary
> >complexity, and there are others who back up 10000 nodes across 50
> servers and
> >wouldn't mind the complexity if it added useful function.
> >My thinking is that a cut down set-and-forget general purpose database
> >implementation would suit the first crowd, i.e. the black box of today
> but with
> >a prepacked/configured DB2 or Oracle instance, whilst those with somewhat
> bigger
> >needs could pay for a TSM consultancy to tune the many knobs on their
> database,
> >and the really big guys buy a full version of the same database and go
> all out
> >with it.
> >
> >PS Just so's you know, I'm a DB2 bigot and having now worked with Oracle
> for a
> >while would only use Oracle for non-technical reasons such as
> availablility of
> >local expertise were I given a choice of database by my application.
> >
> >Steve Harris
> >AIX/ADSM/Oracle/HACMP guy
> >The Wesley Hospital
> >Brisbane Australia.
> >
> >
> >
> --- EDITED FOR BREVITY! (and to conserve electrons) ---
>
> *---------------------------------------------------------*
> Matt Bacchi                              mbacchi AT us.ibm DOT com
> IBM Global Services                    v2bacchi AT btv.ibm DOT com
> D54V Server Infrastructure                   (802) 769-4072
> ADSM & AFS/DFS Backup                        (tie) 446-4072