Do you have Windows 2000 clients?  If so, this audit is not going to cleanup
all of the system object related stuff.  It takes 4.2.3.2 to do that and the
cleanup backupgroups command is the recommended approach vs. an AUDITDB.

Support and Development are pretty adamant about not running AUDITDB unless
you have a real problem.  What problem are you trying to solve?

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Jurjen Oskam [mailto:jurjen AT QUADPRO.STUPENDOUS DOT ORG]
Sent: Saturday, January 11, 2003 7:45 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: AUDITDB reports same "Processed <xxx> database entries>" every time


Hi everybody,

I'm running an AUDITDB on our TSM database (3 GB, 4.2.2.13 server on AIX
4.3.3 ML10).

I have used the FILE= parameter to redirect the output to a file. The
auditdb started off OK, but for the last hour it has been reporting
the same amount of processed database entries:

ANR4140I AUDITDB: Database audit process started.
ANR4075I AUDITDB: Auditing policy definitions.
ANR4040I AUDITDB: Auditing client node and administrator definitions.
ANR4135I AUDITDB: Auditing central scheduler definitions.
ANR3470I AUDITDB: Auditing enterprise configuration definitions.
ANR2833I AUDITDB: Auditing license definitions.
ANR4136I AUDITDB: Auditing server inventory.
ANR4138I AUDITDB: Auditing inventory backup objects.
ANR4307I AUDITDB: Auditing inventory external space-managed objects.
ANR4139I AUDITDB: Auditing inventory archive objects.
ANR4137I AUDITDB: Auditing inventory file spaces.
ANR4310I AUDITDB: Auditing inventory space-managed objects.
ANR4306I AUDITDB: Processed 63092 database entries (cumulative).
ANR4306I AUDITDB: Processed 141783 database entries (cumulative).
ANR4306I AUDITDB: Processed 202646 database entries (cumulative).
ANR4306I AUDITDB: Processed 253108 database entries (cumulative).
ANR4306I AUDITDB: Processed 319353 database entries (cumulative).
ANR4306I AUDITDB: Processed 321014 database entries (cumulative).
ANR4306I AUDITDB: Processed 321014 database entries (cumulative).
ANR4306I AUDITDB: Processed 321014 database entries (cumulative).
ANR4306I AUDITDB: Processed 321014 database entries (cumulative).
ANR4306I AUDITDB: Processed 321014 database entries (cumulative).

 ... and so on, with dozens of copies of the last line, ie. it doesn't
seem to be progressing past 321014 database pages. The dsmserv process
still consumes CPU time (this is a 4-CPU machine, and the dsmserv process
consumes about 1 CPU worth of CPU time), but iostat on the volumes the
database is located on is showing very little I/O activity: every few
seconds a little burst of about 50 KB read or write activity.

The database- and log-files do have increasing timestamps, so they are
being written to.


For a DR-test a few weeks ago, I have restored this database to a little
RS/6000 (512MB RAM, one internal SCSI drive, 333MHz CPU), and audited that
database: it took about nine hours. The production machine is on an
7026-M80 with 4 CPUs and 2 GB RAM.


I am worried about the number of processed databage pages remaining
constant. Did anybody see this before? I have searched the archives
but couldn't find this.

Thanks,
--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/