>Ifthe 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?

In general, I've found ADSM to be pretty failure-resistant. You
should obviously be taking periodic DUMPDB snapshots of the
database using the consistent dump parameters. Using those, you
can restore the database without requiring the AUDITDB, which is
something to be avoided if at all possible. In the case of power
failures or system crashes, usually the double commit will
protect you against inconsistencies in the database. The cases
when it doesn't protect you usually involve media failure.

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

ANR9999D messages in the console and activity log are usualy a
good clue that something nasty has happened. There are also
specific errors that will appear in the console and activity logs
for "anticipatable" errors, and the server will not start.

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

If an AUDITDB is required, usually messages will appear to tell
you to do one. If not, level 2 is very good about handing out
aspirin with requests to do AUDITDB's...8-).

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

No joke. Sometimes you're looking at *days* of wall time for a
good-sized database. AUDITDB is something to avoid whenever you
can -- it's worth a few more precautions to prevent it.