I last did a full AUDITDB several years ago, and it took a week. Now it
would be an impossibility, as it is for you too. Call support and ask
about auditing just a part of the database at a time. For instance, I
once audited just the part that covered the online disk storage pools
with the undocumented option:

  dsmserv auditdb diskstorage fix=yes ...(other options)

This took less than an hour, and fixed my database corruption. (Your
Mileage *WILL* Vary!!!)

There may be other special options that let you break up the audit
process further into manageable chucks; call Tivoli support.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu


On Mon, 5 Aug 2002, John C Dury wrote:

>The scenario:
>     Recently I was trying to upgrade to TSM server v5.1.1.2 from v4.2.2.7
>on AIX on our production database. The server failed to start after the
>upgrade and according to IBM, it's due to a corrupt DB. They informed me
>that we need to run a "DSMSERV AUDITDB INVENTORY FIX=YES" on our database
>which must be done with the system down. I started it on a Friday and let
>it run all weekend ubt it still hadn't finished by monday morning.
>Unfortunately we use TSM to backup our Oracle transaction logs and without
>that, we tend to run out of space on the AIX servers that have Oracle.
>Leaving our production TSM system down for several days is just not
>possible. IBM has given me a workaround for upgrading to v5.1.1.2 but it
>would still mean a corrupt database.
>     Obviously I'd like to fix things but here are my concerns. We ran into
>a problem long ago that given a certain setup scenario, a normal backup
>from a client to the TSM server could corrupt the database. Granted this
>was when our TSM (ADSM then) server was on MVS, but how do I know that
>after fixing the DB, there isn't a client out there somehow corrupting the
>database again? Leaving our production system down for a long period of
>time just seems idiotic and also quite probably, impossible. What have
>others done? Our DB is about 25000 meg but only 79% full.
> Is there anything I can do to speed up the process?
>Is there anyway to tell  what client object #1996898 is referencing when
>the output from the "auditdb inventory" looks like:
>
>ANR4306I AUDITDB: Processed 1996898 database entries (cumulative).
>
>The output appears to be in sequence (for the most part) and I was thinking
>I could just delete the backup data for that client in hopes of removing
>the corrupt entries.
>
>I hope someone has a suggestion/idea because leaving a production system
>down for many days is just ridiculous and not feasible really.
>
>John
>