Joel,
I think that your suggestion would help, but I would go a little bit
further. To some degree, we already have what you suggest: in my case,
I could restrict the AUDITDB to the storage part of the database
(dsmserv auditdb storage fix=yes). But this is the biggest part of the
database, so this does not help much. The partitioning must be much
more fine grained as you suggest, and, very important, there must be
some means to identify that part of the database needing an audit, so
that i do not have to run it on the whole DB.
How could these means look like? First: If we have to run an AUDITDB, there
must be some problem, and a closer investigation of that problem should
indicate, which part of the DB to look at. Second: An online AUDIT DB FIX=NO
could be run to identify that part.
Regards,
Reinhard
Joel Fuhrman writes:
> 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
> >
>
--
Reinhard Mersch Westfaelische Wilhelms-Universitaet
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
|
