Trevor,

I can't comment directly on your specific situation because our environment
is much different (OS/2 ADSM Server w/ 8mm tape drives).

However, it has been our experience that a db restore will take 2-3 times
(minimum) the amount of time required for the corresponding dump, given the
same environment for both the dump and restore.  We asked IBM about that
once (these were not practice situations; these were recovering production
systems w/ db errors) and we told that the dump process doesn't dump the
entire contents of the database; it just dumps a subset of the database
that is required to do a restore.  The restore, we were told, reads those
minimal records and rebuilds the entire database.

Dennis Schaffer
Mutual of Omaha


To:       ADSM-L @ VM.MARIST.EDU
cc:        (bcc: Dennis Schaffer)
From:     Trevor.Foley @ BANKERSTRUST.COM.AU
Date:     08/14/97 06:02:29 PM ZE10
Subject:  ADSM database restore taking a l-l-l-o-o-o-n-n-n-g-g-g time




Hi,

We are currently moving an ADSM environment from one ADSM server to another
and the restore of the database on the new machines is taking what we
consider to be unacceptably long.

The original machine is an RS/6000 R40 dual processor running AIX 4.1.5 and
ADSM 2.1.5.12, I don't have the versions of Atape and atldd handy but they
are the ones that were required/recommended for ADSM 2.1.5.12. The new
machine is an RS/6000 R50 dual processor running AIX 4.2.1, ADSM 2.1.5.13,
Atape 3.1.1.0 and atldd 3.1.0.5.

The backup of the database, which is 12 gb, 60% utilised, takes 40 minutes
to 3590s on the R40 when unloaded. We have run the restore 3 times so far
(2 trial runs) and each time has taken in excess of 5 hours.

The command that we are using is:

     dsmserv restore db devclass=atl3590 volume=d90179 commit=yes

For those of you who have done a restore of a database of this size, are
the times we are seeing surprisingly long (I sure hope so)? Any suggestions
for trying to shorten this time? We are going to try the restore on the R40
after the move and compare results.


thanks,

Trevor