I'm sorry you had a bad experience with Restore Volume.  As you are now aware,
restoring files from a non-collocated copy pool to a collocated pool can be
painfully slow.  IMHO, this is not a fundamental design deficiency with this
operation, but is a natural consequence of moving data from non-collocated
sequential volumes to a collocated target pool.  To minimize mounts in the
target storage pool, files are copied by node/filespace and the extra
processing to do this can be significant.  The same problem can occur for
Restore Stgpool, which works in a very similar manner.

However, you do not need to avoid these operations as you would the plague,
since there are a some things you can do to greatly improve performance.

o If you have not applied the PTF with the fix for APAR PN87901, please
  do so.  For the AIX V2 server, that should be level 10.
o As explained in the closing text for PN87901, it is usually much
  faster to restore data from your non-collocated copy pool to a disk
  pool and then let the data migrate to the collocated pool.  This may
  seem like a roundabout way to do things, but the overall throughput
  is usually *much* better.
o Migrate to Version 3. Restore Volume and Restore Stgpool were not
  specifically redesigned in Version 3. However, Version 3 does use a new
  storage model called file aggregation which should greatly improve
  performance   for certain operations involving files that have been backed
  up or archived   to a Version 3 server.  Restore Volume and and Restore
  Stgpool should both  perform much better for such files.

Dave Cannon
ADSM Development

        ADSM-L AT VM.MARIST DOT EDU
        10-24-97 09:01 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet

To: ADSM-L AT VM.MARIST DOT EDU @ internet
cc:
Subject: Observations on Restore Volume

>    I decided to see what a Restore Volume operation was
>like.  A preview revealed that 12 copy storage pool tapes would be inputs.
>(Our copy storage pool is not collocated; our primary tape pool is.  The
>destroyed tape was 17% full.  The non-dedicated server has two 3590 drives.)
>    The restore took some 20 hours over three days.
>    In any case, Restore Volume can be a horrendous operation, which I hope
>receives redesign in ADSM V.3.  Suffice to say, the next time I have a damaged
>tape I will do whatever I can to render the tape usable for the duration of a
>Move Data, rather than resort to Restore Volume.