> Server(5500), 1 GB memory, 3494 with 3590-b ultra-scsi drives. My database
> is 8 GB spread across two volumes.  It took me almost 6 hours to restore my
> database a couple of months ago.
>
> The ADSM server is at 3.1.2.14. I am also hoping that maybe somehow
> 3.1.2.40 will help this problem. Unfortunately I don't want to go to
> 3.1.2.40 until IBM fixes all the problems they keep
> introducing/reintroducing in the new fixes.
>
> I have talked to Steve Roder on this list who was able to work with IBM on
> getting some new code just for SUN restores. He has reduced his restore
> times using this new code. Maybe Steve can comment more on this and what
> the code actually does. Or maybe IBM has some information for us?

For one of my restore DB's IBM gave me a dsmserv module that did not call
sync, and the formatting of the log was reduced from 6 hours to 20
minutes.  Back in Feb when I had to restore my 54GB DB (assigned capacity,
using 11,860,152 pages) via 3.1.2.13, it took 3 hours to restore the full,
and another 90 minutes to apply an incremental of 286817 pages, and format
a 2GB recovery log.  I repeated this a couple weeks later (also on
3.1.2.13 (FIXTEST Server: IC227562 (orig.AIXapar IX85298) for 12,155,368
pages in 5 hours 45 minutes, and an incremental of 245808 in an additional
60 minutes, and a second incremental of 429115 in 90 minutes, and a third
incremental of 422536 in 2 more hours.  The final incremental, with
commit=yes, always formats the 2GB recovery log.

I honestly can't recall if the above timings used the no-sync module, but
if restoredb times have grown that dramatically in 3.1.2.14 and above, it
makes me wonder if IBM introduced a problem somewhere along the way...

Steve (unVMix Systems Programmer/Dude) Roder
(tkssteve AT ubvm.cc.buffalo DOT edu | tkssteve AT acsu.buffalo DOT edu | 
(716)645-3564 ,
   | http://ubvm.cc.buffalo.edu/~tkssteve)