ADSM-L

Re: ADSM DB Reorg necessary after expiration processing ?

1999-11-14 18:27:28
Subject: Re: ADSM DB Reorg necessary after expiration processing ?
From: Trevor Foley <Trevor.Foley AT BTFINANCIALGROUP DOT COM>
Date: Mon, 15 Nov 1999 10:27:28 +1100
G'day,

Bill and Michael, I'm with you. I've even gone as far as to suggest this 
directly to a number of people with ADSM/TSM development. The ADSM developers 
should be developing the best backup product that they can, rather than 
developing yet another relational database.

The responses that I have received from ADSM development include (with some 
paraphrasing on my part) 'we've always done it that way', 'there would be DB2 
licensing issues' (and this is at the time when both ADSM and DB2 belonged to 
the same company! to 'the ADSM database has been specifically developed for 
ADSM and other generic databases would not be able to provide the same level of 
performance'.

I don't believe that any of these problems are insurmountable.


Trevor

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