Original question since it's been a few days:
--------
Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN
All the dasd can be backed up in 1:15 (hh:mm), but restore takes 5:08.
Are we doing something wrong, or is this 4.5x longer normal?
--------
We are talking real physical 3590 tape drives. (2g ficon)
We are talking about 400 3390-3 equivalents (some are -9s) (IBM 8300)
Backups are done with CICS up, but no users. (this is a dr box test).
Restores are done with nothing up on a recovery system.
Same physical CPU, same Disk, same tape drives.
Tapes are not rewinding and repositioning between backup files.
We are just trying to understand if this is normal or not.
Tony Thigpen
Tim Hare wrote on 09/21/2015 10:47 AM:
Does the tape subsystem have physical tape cartridges? If so, then tape
mounts are probably a big part of the time involved. I can only speak to the
IBM TS 7700 I last used before I semi-retired, which had high-capacity tape
cartridges.
1. Scratch tapes are 'fast ready' (I think that's the term) - there's no mount
time as long as your disk cache has space for virtual tapes. So writing a
bunch of tapes incurs very little mount time.
2. When doing a restore, first you load the physical cartridges into the VTS
before you ever start any jobs.
3. When you run the restore job, there's _nothing_ in the disk cache.
4. Therefore, every virtual tape mount is a cache miss and requires a recall.
5. Recall is a mount, fast forward to the virtual tape's position, reading the
virtual volume from the tape and writing it to the disk cache, _before_ your
virtual mount is satisfied.
6. If you run multiple restore jobs, and they refer to virtual tapes on the
same physical cartridge, you will have contention for the physical tape (which
you don't see in any monitor on zOS! )and one job's virtual mount will have to
wait on the other one's.
As you can see there are quite a few delay points in a restore.
I created a SHARE enhancement request (in the Storage project) that I hope IBM
will implement, which would help with some of these delays. Basically, it would
be an HMC enhancement on the VTS so that you could indicate that you are
loading tapes for DR, and when that indicator was set, each tape loaded would
immediately be mounted, and have its virtual tapes written to the disk cache,
up to some threshold of the cache. Doing so would help alleviate the problems
in 3, 4, 5, and 6.
I don't know of good ways to pre-mount the tapes and therefore pre-load the
cache from zOS but it might be possible. It's also possible, if you use BVIR
to retrieve data telling you which virtual tape is on which physical cartridge,
to try to split your restores by physical cartridge to try to eliminate some of
the physical mount contention.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
