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