I asked Development about this, causing some head-scratching. They'd
like you to open a PMR so they can dig into why this could be happening.
Tony Thigpen wrote:
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.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
