Hi everybody,

you might remember my recent mail about my problem with AUDITDB: the
AUDITDB progressed *very* *very* slowly. After upgrading to 4.2.3.2,
I ran CLEANUP BACKUPGROUPS. (That caused the log to fill up rather quickly,
so I had to cancel that process to allow the log to empty itself a few
times.)

Before the CLEANUP BACKUPGROUPS, the database consisted of 3 mirrored
volumes of 1 GiB each, with a utilization of 72,2%. After the CLEANUP
BACKUPGROUPS, the utilization dropped to 62%. Since we're planning to
upgrade to TSM 5.1 soon, I took advantage of the scheduled downtime to do
an UNLOADDB/LOADDB/AUDITDB. The UNLOADDB and LOADDB worked perfectly, each
took about 30 minutes (7026-M80, 4CPU, 2GiB RAM). After the
UNLOADDB/LOADDB, the database utilization dropped like a stone to 37%.

The following AUDITDB also took only 35 minutes, and found a few
inconstencies. What the AUDITDB also did was report inconsistencies about
several schedules, both administrative and client. It reported that it put
default values in those schedules.

What happened was that every schedule that had a PERU=ONETIME before the
AUDITDB, now had a PER=1 and PERU=DAYS, and (in the case of an admin.
schedule) was actived as well! (Mind you, this included the schedules
created by an immediate client action; all those were also activated and
scheduled to be executed daily) This was No Fun. Fortunately, I had started
the server with DISABLESCHEDS enabled, but I had to correct the affected
schedules.

My question is: has anybody else experienced this behaviour? (ie. AUDITDB
changing schedules to execute each day)


--
Jurjen Oskam

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