ADSM-L

Re: Using db2 or oracle or whatever for the TSM DB

2015-10-04 17:37:12
Subject: Re: Using db2 or oracle or whatever for the TSM DB
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
To: ADSM-L AT VM.MARIST DOT EDU
Yikes!  NO WAY do I want ADSM based on another vendor's data base.

Has nothing to do with performance - has to do with the fact the the DB
operation is CRITICAL to keeping ADSM alive and well, and the LAST thing we
need is to have to involve another vendor to get response to DB issues.  How
would that be a good thing, or make *SM a better product?

And in my past experience with another IBM product that used DB/2 as it's
data base underneath, involving DB2 creates just as big a support problem as
if it were a totally unrelated vendor.  I NEVER want to hear "we can't fix
that until DB2 fixes their problem..... ", or the like, EVER again.

And besides that, I LIKE the fact that I don't have to learn DB2 or Oracle
to make ADSM work.

If it ain't broke, don't create ways to break it.....

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************





> -----Original Message-----
> From: Bill Colwell [SMTP:bcolwell AT DRAPER DOT COM]
> Sent: Tuesday, November 16, 1999 12:57 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Using db2 or oracle or whatever for the TSM DB
>
> Rick, I guess you just have a more active imagination than me! ;-)
>
> I sent a note to someone at Tivoli about this and he replied in part --
>
>     "I agree that we need to look at using an industry
>      standard DB for high-end customers.
>      Keep pushing for this with other customers.
>      Make sure our marketing group understands."
>
> So what does everyone think of this?  Would you want TSM to use
> db2/oracle/whatever for the database?  Would it be easier to backup/reorg
> tune?  Would you think that your backups are more secure?
> Would TSM be a better product?  If performance went down, how much of
> a decrease would you accept?
>
> So let's hear it!  Here's your chance for input to a major change in
> TSM.
>
>
> --
> --------------------------
> Bill Colwell
> C. S. Draper Lab
> Cambridge, Ma.
> bcolwell AT draper DOT com
> --------------------------
>
>
> In <199911161303.IAA07261 AT gatekeeper.firstenergycorp DOT com>, on 11/16/99
>    at 08:03 AM, "Richard L. Rhodes" <rhodesr AT FIRSTENERGYCORP DOT COM> said:
>
> >This is an interesting discussion.  Let me give a view from someone
> >evaluating ADSM/TSM.
>
> >We don't have DB2. What we do have is an extensive infrastructure
> >setup to handle Oracle (backup, recovery, DR, tuning). If ADSM/TSM
> >required a full DB2 installation we would have to do the same for it -
> > which I personally would be very reluctant to do.  To me, a backup
> >system should not require that I become fully competent in a DB that
> >we have no other use for (currently - all things change).  There are
> >too many other good backup products on the market that don't require
> >you to become db administrator for DB2/ORacle/Sybase/etc for
> >IBM/Tivoli to make this a requirement.  I believe if IBM/Tivoli did
> >this they would limit the market into which ADSM/TSM could be sold.
>
> >So, as far as I'm concerned, I'd want the db to be Oracle or the
> >internal db - but not DB2!
>
> >The question IBM/Tivoli continually has to answer is:  what customer
> >is ADSM/TSM being targeted at?  If the answer is DB2 shops, then it
> >would make sence to use DB2 as the db.  If the answer is broader than
> >DB2 shops, then requiring DB2 makes little sense.
>
> >Just some thoughts . . . .
>
> >rick
>
> >----------------------------------------------------------------------
> >Richard L. Rhodes     e: rhodesr AT firstenergycorp DOT com
> >Ohio Edison Co.       p: 330-384-4904
> >                      f: 330-384-2514
<Prev in Thread] Current Thread [Next in Thread>