ADSM-L

Re: Performance degradation and Size of database

1999-09-02 09:02:37
Subject: Re: Performance degradation and Size of database
From: Richard Sims <rbs AT BU DOT EDU>
Date: Thu, 2 Sep 1999 09:02:37 -0400
>my 2 cents ... I have a 25GB DB which is 50% full, I had before a 9GB DB.
>I erroneously supposed to Audit-DB it. With the previous one I managed to
>do it a couple of time, now after 26 hours and 135.000.000 entries, I
>decided that I'm using a huge DB and I interrupted the operation at my
>own risk!

To repeat advice I got from IBM ADSM management: If you encounter any problems
with the performance of ADSM facilities, FILE A PROBLEM REPORT.  Do not live
with grossly inefficient functions like Audit DB or assume that they should be
this slow.  The ADSM recovery utilities have gotten virtually zero development
attention over the past two versions of ADSM and perform like it.  Development
attention goes to the "normal operation" facilities, and so recovery aids get
neglected, meaning that when your shop has to perform an ADSM recovery, the
pain is compounded.  (Indication: Have you ever seen ADSM recoverability
proferred by Marketing as an ADSM selling point?)  It's sad that we should
have to file problem reports to get these areas addressed, but that's the way
it is.

As other customers have indicated, a 25GB DB is not overly large, and it
should serve you well.  ADSM is supposed to be an Enterprise Product, after
all.  Recoverability should not have to be a limiting factor on the practical
size of the ADSM database.  Any time you have to do a recovery and find it
taking far too long (and certainly "days" is absurd), file a problem report.
It's the only way we'll get these utilities fixed.

    Richard Sims, BU