David already answered many of the questions below...but since
ADSM V2 is also mentioned, I wanted to add that in ADSM V2, the
auditdb will not be needed during restores of the DB.  Our new
BACKUP DB function copies the database in a self consistent
format that eliminates the need for a DB audit on recovery of
the database.

A database audit might still be needed if the database becomes
corrupted...but since an early release 1 bug was fixed, this
is becoming very rare.  With ADSM V2, I would probably
call IBM support before ever doing a database audit.

ADSM V2 functions should bid a not-so-fond farewell to the
DB audit step....

Greg Tevis
ADSM Technical Support

 ========================================================================
Hello there.

I am starting to sketch recovery procedures for an ADSM V2 that we will install
here very soon. I would like a few words of advice (especially from the
IBM-ers) on the next topic.

If the platform on which my ADSM server runs suffers from system crash or power
down or ADSM crash, would it be recommended to perform systematically an
auditdb of the ADSM DB, once the platform becomes available again or when my
ADSM is   restarted on an alternate platform, or can I count on the fact that
ADSM has enough build-in fail-safe mechanism that the DB will not be corrupted
in such a situation?

If my DB becomes corrupted, how/when will I realise that such an event has
occured?

If performing an auditdb is "normally" not required after such an incident, how
can I know whether or not to do it?

The reason of these questions is that we are planning to create a rather big
ADSM configuration here, and that we suspect that the auditdb would be
extremelly costly to run in such an environment.

Thanks for any help.