Hello ADSM DB "recoverers",

Yes, it's true that the LOADDB is very very slow:
After 69 hours processing, only 2/3 of the data was reloaded (21of 30GB)
when a stupid I/O error on cartridge has stopped the process.

Yes, it's true that the LOADDB uses more DB space to restore the same data:
After reloading 2/3 of the data, the DB was at 88% full. No chance to
complete without a serious DB space increasing.

Result: Please rip off the pages of your ADSM Administrator Guide and
Reference explaining the DUMPDB and LOADDB commands. There are dangerous and
incorrectly documented ! (send them back to Mister or Miss Tivoli. ;-)

Now: We are running a RESTORE DB who is very faster (+/- 2/3 done after 8
hours)
BUT: I have now to run a point in time DB restore because I had to reformat
the recoverylog before to start the LOADDB, so, with the Restore DB at the
last incrback , I loose +/- 12 hours of processing (Expire inventory,
Migration, Copy to copypool, some clients backups or archives......). There
will be many inconsistances between the DB and the storagepools. Many AUDIT
VOLUMEs to do..... with maybe many other bad surprises.

DO NEVER USE THE DUMP - FORMAT - LOAD DB PROCEDURE WITH A BIG DB (> 20 GB)

Pleased to share (bad) experience

Francis