Ref:  Your note of Wed, 21 Sep 1994 13:56:20 +0200 (attached)

>Recently, we got problems with our ADSM database (expiration processing
>died with messages ANR0104E and ANR0865E, backups were not found). So we
>brought our old ADSM/MVS server (level 0) to level 0.9/1.9. I then tried
>AUDITDB, which was not able to solve the problem.
>
>So I did a DUMPDB, followed by INSTALL and LOADDB, and I am currently
>running AUDITDB again, hopefully having an intact DB afterwards.
>
>Now I am concerned about the long time these processes need. DUMPDB was
>o.k., but loading the 300 MB database took 11 hours wall clock time
>(14100 CPU seconds) and AUDITDB is now running since 17 hours, having
>inspected about half of the database. A former AUDITDB FIX=NO took
>21 hours wall clock time and 29700 seconds CPU time.
>
>I must admit, the ES9000-190 we are doing this on, is a quite small
>machine and we are planning to migrate to ADSM/6000. But we also expect
>our database to increase substantially. So this form of database recovery
>will probably make no sense.
>
>Any suggestions on how to plan for database recovery in the future?

ADSM Development does indeed understand that the current database
dump/load and audit process is waaaay to long running to be
practical when fast recovery of the server is necessary.

Informational APAR II08040 describes enhancements that we recently
introduced to produce a consistent database dump image, and thereby
completely eliminate the need for a database audit (AUDITDB) after the
the database is reloaded.  In fact, you could have used that method
to eliminate the AUDITDB that you are currently running.

The on-line DUMP DB CONSISTENT=YES command can be used to produce
a consistent database dump so that an AUDITDB is not required
after the server database is reloaded from the dump.

In addition, development is actively working on solutions that
will improve server recovery time overall.

Mike Kaczmarski
ADSM Server Development