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
On 15 Nov 99, at 17:00, Bill Colwell wrote:
>
> If TSM were to use a standard database, I can't imagine choosing somethig
> other
> than db2.
>
> >I don't believe that any of these problems are insurmountable.
>
> As an example of what can be gained, consider the only tuning knob we now
> have,
> database bufferpool size. In db2 for OS/390 there can be 50 bufferpools.
> There
> are
> 8 tuning values for each pool. The pool size and tuning values can be changed
> dynamically
> at any time. This is far more capability than the TSM developers have been
> able
> to
> deliver with the black box database.
>
> >Trevor
>
>
> --
> --------------------------
> Bill Colwell
> C. S. Draper Lab
> Cambridge, Ma.
> bcolwell AT draper DOT com
> --------------------------
>
>
> >> -----Original Message-----
> >> From: Michael Abel [mailto:Michael.Abel AT RESNOVA DOT DE]
> >> Sent: Saturday,13 November 1999 7:55
> >> To: ADSM-L AT VM.MARIST DOT EDU
> >> Subject: Re: ADSM DB Reorg necessary after expiration processing ?
> >>
> >>
> >> That is indeed a very interesting discussion we often have
> >> with our current
> >> and also prospective customers: why is ADSM not using a
> >> "real" database?
> >> Besides that fact that there is a certain history of the product to be
> >> aware of I can clearly see a lot of advantages, e.g. having a
> >> "real" SQL
> >> interface for managing, reporting etc. But I am not sure of I
> >> (personally)
> >> like the idea of having another complex product besides ADSM on my box
> >> which has to be managed, monitored etc.
> >>
> >> And if Tivoli/IBM would support DB2 I bet there will be a lot
> >> of people
> >> asking for other databases to be supported. This may lead us to "TSM
> >> running on MS SQL Server" (<- just kidding, of course).
> >>
> >> I wonder if someone inside ADSM Server development is willing
> >> to comment on
> >> that - as Bill wrote: we do not expect something in the next
> >> release but it
> >> would be interesting to know if development will firmly stick
> >> to their own
> >> "database" or if there are thoughts to make use of real
> >> database products.
> >>
> >> Regards,
> >> Michael
> >>
> >>
> >>
> >> Bill Colwell
> >> <bcolwell@DRA To: ADSM-L AT VM.MARIST DOT
> >> EDU
> >> PER.COM> cc:
> >> Sent by: Subject: Re:
> >> ADSM DB Reorg necessary after expiration processing ?
> >> "ADSM: Dist
> >> Stor Manager"
> >> <ADSM-L AT VM DOT MA
> >> RIST.EDU>
> >>
> >>
> >> 12.11.99
> >> 19:14
> >> Please
> >> respond to
> >> "ADSM: Dist
> >> Stor Manager"
> >>
> >>
> >>
> >>
> >>
> >> Sheelagh,
> >>
> >> I am not surprised that your db quickly grew to 60G again.
> >> I reviewed some of the material from the Symposium and saw the
> >> foils on db reorg. It appears that the reorg packs the data tight.
> >> This is fine if the purpose is to make the biggest space reduction
> >> during the reorg. But it isn't so good if the database is updated
> >> with random inserts which of course is how adsm works. To plan
> >> for random inserts you need to imbed freespace during the load.
> >>
> >> The first time I used imbedded freespace during a load was with
> >> VSAM on MVS 25 years ago, so it isn't a new concept.
> >>
> >> If IBM really wants to solve all manner of database issues
> >> they should use DB2 for the database. The DB2 product has
> >> already solved backup & recovery, reorg. Performance is
> >> improved in every release.
> >>
> >> I have worked with DB2 for 15 years and have the greatest respect
> >> for it as a robust, stable, and useable product. Tivoli should
> >> stop trying to reinvent the database wheel and fixing their
> >> flat tires.
> >>
> >> Of course I don't expect this in the next release ;-)
> >>
> >> --
> >> --------------------------
> >> Bill Colwell
> >> C. S. Draper Lab
> >> Cambridge, Ma.
> >> bcolwell AT draper DOT com
> >> --------------------------
> >>
> >>
> >> In <E11mEXC-0000rL-00 AT sage.oucs.ox.ac DOT uk>, on 11/12/99
> >> at 11:06 AM, Sheelagh Treweek
> >> <sheelagh.treweek AT COMPUTING-SERVICES.OXFORD.AC DOT UK> said:
> >>
> >> >Hi,
> >>
> >> >The unload/load/DB reorganise functionality is in TSM 3.7.
> >> I did get a
> >> >chance to try this code in July and did the operation on a
> >> 60GB database
> >> >which has been in existance for about 4 years. The gain was
> >> about 20GB;
> >> >the DB ended up just under 40GB and better optimised.
> >>
> >> >It took rather a long time (about two days) - and no service possible
> >> >while you are doing it. Because we were replacing the hardware base
> >> >(RS6000/R40 to H70) in the summer it seemed a good opportunity. It
> >> >worked well, but you don't know at the beginning how long it
> >> will take.
> >> >I think the unload took about 18 hours and the load about
> >> 30. I think
> >> >platform, disks, tape drives all play their part in
> >> determining just how
> >> >long it takes.
> >>
> >> >I'm sure it was worthwhile on a database that was probably very
> >> >fragmented after 4 years. It wouldn't be something to
> >> undertake lightly
> >> >or regularly to regain a small amount of space. In fact the
> >> space gain
> >> >seemed to be temporary in our case as the H70 is doing a lot
> >> more work
> >> >and we have grown again to 60GB! It's hard to say / quantify whether
> >> >performance is better as a direct result.
> >>
> >> >It's a useful addition to the facilities available, especially in the
> >> >abscence of any on-the-fly tuning facilities. Hint hint!
> >>
> >> >And it is much, much faster than the previous unload/load
> >> code - which
> >> >did not have the optimization in (I believe).
> >>
> >> >Hope this helps, Sheelagh
> >> >-------------------------------------------------------------
> >> -----------
> >> >Sheelagh Treweek Email:
> >> sheelagh.treweek AT oucs.ox.ac DOT uk
> >> >Oxford University Computing Services Tel: +44
> >> (0)1865 273205
> >> >13 Banbury Road, Oxford, OX2 6NN, UK Fax: +44
> >> (0)1865 273275
> >> >-------------------------------------------------------------
> >> -----------
> >>
> >>
> >> >>X-Apparently-From: <landrefl AT yahoo DOT com>
> >> >>MIME-Version: 1.0
> >> >>Content-Transfer-Encoding: 7bit
> >> >>X-Priority: 3
> >> >>X-MSMail-Priority: Normal
> >> >>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> >> >>Date: Thu, 11 Nov 1999 20:27:38 -0500
> >> >>From: "Landreville, Frederic Yahoo" <landrefl AT YAHOO DOT COM>
> >> >>Subject: Re: ADSM DB Reorg necessary after expiration processing ?
> >> >>To: ADSM-L AT VM.MARIST DOT EDU
> >> >>
> >> >>At the ADSM Symposium in Oxford... they did talk about unloading and
> >> >>reloading the database... but only under certain
> >> conditions... I will
> >> look
> >> >>for this in the technical manuals...
> >> >>
> >> >>But in general, the Database heals itself pretty well...
> >> >>
> >> >>Frederic Landreville
> >> >>
> >> >>----- Original Message -----
> >> >>From: Joshua S. Bassi <jbassi AT GLORYWORKS DOT COM>
> >> >>To: <ADSM-L AT VM.MARIST DOT EDU>
> >> >>Sent: Thursday, November 11, 1999 10:38 AM
> >> >>Subject: Re: ADSM DB Reorg necessary after expiration processing ?
> >> >>
> >> >>
> >> >>> Andreas,
> >> >>>
> >> >>> No you do not need to reorg your ADSM database. And there is not
> >> really
> >> >>> a way to do that anyway.
> >> >>>
> >> >>> When you say your database didn't get any smaller - do
> >> you mean the
> >> size
> >> >>> of the DB on disk? Or do you mean the % utilized? The
> >> size of the DB
> >> >>> on disk shouldn't shrink per say, but the % utilized
> >> should go down -
> >> >>> but then again I have seen where it didn't go down after deleted a
> >> >>> large amount of client data.
> >> >>>
> >> >>>
> >> >>> Joshua S. Bassi
> >> >>> Senior Technical Consultant
> >> >>> Symatrix Technology, Inc.
> >> >>> jbassi AT gloryworks DOT com
> >> >>> (503) 702-3371
> >> >>>
> >> >>> -----Original Message-----
> >> >>> From: ADSM: Dist Stor Manager
> >[mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> >>>> Andreas Rensch
> >>>> Sent: Thursday, November 11, 1999 2:48 AM
> >>>> To: ADSM-L AT VM.MARIST DOT EDU
> >>>> Subject: ADSM DB Reorg necessary after expiration processing ?
> >>>>
> >>>>
> >>>> Hello,
> >>>>
> >>>> last weekend we ran expiration processing and a lot of data has been
> >>>> expired, because we moved one client (70 GB) to another and all except
> >>>> the most recent backups became obsolete. But - I think - the database
> >>>> didn't become smaller. Do I have to reorganize the database or what's
> >>>> the reason that the database is still so large?
> >>>>
> >>>> Operating System : OS/390 2.4
> >>>> ADSM Server : 3.1.2.40
> >>>>
> >>>> regards / mfg
> >>>>
> >>>> andreas rensch / rz-qs
> >>>> tel : +49(0)6171 66 3692 / fax : +49(0)6171 66 7500 3692
> >>>> mailto:renscha AT alte-leipziger DOT de
> >>>>
> >>>> Alte Leipziger Lebensversicherung aG
> >>>> Alte Leipziger Platz 1
> >>>> D 61440 Oberursel
> >>>> http://www.alte-leipziger.de
> >>>
> >>>
> >>>__________________________________________________
> >>>Do You Yahoo!?
> >>>Bid and sell for free at http://auctions.yahoo.com
>
>
>
----------------------------------------------------------------------
Richard L. Rhodes e: rhodesr AT firstenergycorp DOT com
Richard L. Rhodes e: rhodesr AT firstenergycorp DOT com
Ohio Edison Co. p: 330-384-4904
f: 330-384-2514
|
