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:[EMAIL PROTECTED]] Sent: Saturday, January 11, 2003 7:45 AM To: [EMAIL PROTECTED] 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/
