Norm,
The LOADDB time you're seeing is probably in the right neighborhood for
21 million table rows.  The reason it is significantly higher than the
DUMPDB time is that LOADDB transactionally inserts all records from the dump,
while the dump doesn't incur any logging overhead.

If you were to upgrade to a V2 server, you could use the DB BACKUP/RESTORE
facility to move your server.  Instead of doing 21 million record inserts,
it would restore database page images, which should reduce the elapsed time
significantly.

Wayne Hineman
IBM Almaden Research Center
***** Original append follows *****

   As a test run prior to doing a real ADSM/6000 server move, I ran
a DUMP DB (Consistent=YES) on my ADSM server which is at ADSM service
1.2.0.9. It took 58 minutes to dump 479,000 database pages and 21+Million
database entries which I was very pleased with.
   I then did the DSMSERV INSTALL on the target machine followed by the
DSMSERV LOADDB using the dump that I just completed. The ADSM server is
at the same maintenance level and the machine is identical, a RISC 980B.
I was surprised to see that the LOADDB took just less than 18 hours! It
looks like everything restored properly, which is good, but the database
load took longer than I anticipated.
   Has anyone else had experiences similiar to this, and is there anything
that anyone could offer that can be done to lessen the elapsed time of the
LOADDB? Or is this in the neighborhood of what I should expect?

Thanks,
Norm Russell   (nrussell AT vnet.ibm DOT com)
------------------------------------------------------------------------
Norm Russell, IBM Microelectronics, Distributed Computing Services
Norm Russell, IBM Microelectronics, Distributed Computing Services
IBM e-mail: nrussell AT btv.ibm DOT com  Internet e-mail: nrussell AT vnet.ibm 
DOT com
Tel: 802-769-4088 (tie: 446), Fax: 802-769-4253 (tie: 446)
------------------------------------------------------------------------
=========================================================================