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