>    We had a restore from *sm (ADSM 3.1.2.55 running on AIX 4.3.2). It took 16
>hours for 10 Gig.
>
>It was a SAP(financial db)  restore, it took 1 hour for 4 G for the db, then 
>the
>rest for the other files. We saw message like
> "mounting offline tape " and then restore files.
>
>We had collocation turned on in Feb 2000 which we thought would help restore.
>I believe all of our nodes have been collocated.
>We have 18 primary storage  dltpool tapes storing  580 gig for this SAP node.
>Can anyone explain why the restore is so SLOW. Is  it  *sm or network ?
>
>I think  *sm smart should be enough to minimise tapes mounting when files are
>scattered across
>a numbe(in this case 18) of tapes. Does restore have higher  priority than 
>other
>processes?

DLT's inferior start-stop performance will certainly slow you down when
restoring miscellaneous smaller files.  The "1 hour for 4 G" in restoring
the single (?) database file should be at DLT streaming speed, thus
leaving you limited by network speed.
To get a sense of what your limiting factors are, it helps to watch the
process as it happens, with Query SEssion snapshots, operating system
monitoring, and network traffic inspections.
You didn't tell us what kind of collocation you had turned on.  Choice of
type involves trade-offs in terms of how long it takes to do daily backups
versus restorals.  You can perform server queries to check for how
collocated your volumes really are.

Have a look at the "Restoral performance" entry in my ADSM functional
directory at http://people.bu.edu/rbs which has tips accumulated over
the years.  There, also, see the "Restore Order" entry, addressing your
next-to-last question.  Your last question is addressed in the Admin Guide
topic Preemption of Client or Server Operations, which says, as you'd
expect, that restore/recall operations are more important than some
other operations.

Vagaries in *SM client-server software can certainly affect restoral
performance (as witness v3 No Query Restore issues, still unresolve from what
I can see); but site choices in technology and configuration are major
factors.  There typically isn't site management interest in devoting time
and money to these issues - until the rubber meets the road in trying to
restore data in a crunch.

   Richard Sims, BU