I will be doing an offline audit today on my 1.8 GB AIX based database. I
was originally told it could take weeks which is totally unacceptable. So I
ran the audit on a test system it took about 24 hours. Based on the 72
hours for 7 GB from below and on my results, the audit is taking about 12
hours per gigabyte (at least for smaller data bases).
I have on open PMR into which I can add a requested change. The second
level said she would write it up as a change request.
I would like your suggestions. My thoughts are that the server can not be
down for more than say 8 or 12 hours at a time. Thus the audit process
needs to be broken into independent steps. Each step would audit a data set
or a group of data sets. After any step, the server could be returned to
production. Then when time permits, which could be weeks later, the next
step in the audit sequence would be run. When you finish all the steps you
would have a clean database.
On Thu, 20 Jan 2000, Reinhard Mersch wrote:
> Hello Rene,
>
> are you saying, that you ran an online AUDIT DB FIX=YES (i.e. on a
> running ADSM server)? IBM strongly recommended to me, not to use the
> FIX=YES option on an online AUDIT DB, and to run it offline instead.
> Since I cannot afford such a long downtime of the ADSM Server (our DB
> is 28 GB), I am living with our "structural database problems" (according
> to IBM) since 6 month now. It would be nice to hear, that an online
> AUDIT DB FIX=YES can savely be done.
>
> It seems to me that others are in a similar situation (see contribution
> from Brian Nick yesterday on this list), and that Tivoli should have a
> closer look at this. Running an offline AUDIT DB is not an answer.
>
> Regards,
>
> Reinhard
>
> Lambelet,Rene,VEVEY,FC-SIL/INF. writes:
> > Hello,
> >
> > our audit DB run for 72 hours (OS/390, 120 mips cpu!) and then completed
> > successfully. It corrected a few errors from old expires. Our DB is 7 GB .
> >
> > As this audit runs in // with any sessions or processes, I would advice to
> > not cancel it.
> >
> > Best regards,
> >
> > Rene Lambelet
> > Nestec SA - 55, Av. Nestle - CH-1800 Vevey
> > Tel: ++41'21'924'35'43 / Fax: ++41'21'924'45'89
> > E-Mail: rene.lambelet AT nestle DOT com
> >
> >
> >
> > > -----Original Message-----
> > > From: Michael Dummitt [SMTP:Michael.Dummitt AT ROSSNUTRITION DOT COM]
> > > Sent: Wednesday, January 19, 2000 4:02 PM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: Re: "FULL" volume has no data - but unable to delete the
> vol
> > >
> > > I have a similar problem. Cannot delete an empty storage pool DASD
> volume.
> > > Talked with support and their diagnosis was the same...Audit DB. I tried
> > > to do
> > > an Audit
> > > DB, it ran for 72 hours and then I cancelled it. I have an 11 G data
> base.
> > > So
> > > we are
> > > holding off for a better Audit DB. Or some other Miracle.
> >
>
> --
> Reinhard Mersch Westfaelische Wilhelms-Universitaet
> Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
> Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
> E-Mail: mersch AT uni-muenster DOT de Fax:
> +49(251)83-31653
>
|
