Hi,

there is a PMR which maybe discribes your situation, but there is still no fix
for it:

PMR 24630


PMR IX87848

 ERROR DESCRIPTION:

 Traversing down multiple sub directories and then issuing

 a restore on a small number of files can result in a delayed

 start of the restore if the program decides to go through

 the No Query Restore path. This customer has seen a delay

 of 40 minutes until the restore started.

 After enabling the TESTFLAG DISABLENQR (and thus going

 through the Classic Restore path), restore started with

 acceptable delay.

 LOCAL FIX:

 use TESTFLAG DISABLENQR



Winfried




---------------------- Weitergeleitet von Winfried Heilmann/Degussa AG/DE on
DE on
30.07.99 14:39 ---------------------------


ADSM: Dist Stor Manager <ADSM-L AT VM.MARIST DOT EDU> on 30.07.99 14:29:12
Bitte antworten an ADSM: Dist Stor Manager <ADSM-L AT VM.MARIST DOT EDU> @ 
INTERNET
An: ADSM-L <ADSM-L AT VM.MARIST DOT EDU> @ INTERNET
Kopie:
Thema:  Re: Degraded restore performance

>However a few days back an attempted restore of 30 active files of 20Mb took
>almost 20 minutes. A few other trial restores gave similar results.
>
>I must admit collocation is not turned on. But the session seems to be run
>state and not waiting for media.  The CPU statistics reveal that it is IO
>bound by the disk containing the dbvolumes

Sri - This is one of those questions which your own analysis will probably
      tell you more about than any guesses that anyone on the List can supply
based upon the limited info.  A simple lookup of 30 entries in the ADSM
database is not going to overload the database.  We don't know what else was
going on in ADSM at the time, or what else may be on the disk(s) containing
the database, but something else seems to have been driving the load up.
Beyond that we can only advise the usual analysis of watching a test session
from the server, observing any progress indicator on the face of the drive or
stats you can inquiry from it, running opsys performance monitors during the
operation, examining any errpt entries from that time, etc.  In short, you
should perform a controlled experiment to see where the delay is.
    Richard Sims, BU