My customer is having an issue with extended restore times with ADSM.
Here's the environment:
Server Environment:
ADSM for MVS 3.1.2
256MB Region size
3494 with 4 3590 Drives
ADSM DB: ~4.5GB, on IBM RVA disk
Client Environment
Win NT Server 4.0
Dual PII with 1GB RAM
ADSM NT Client 3.1.0.6
The customer lost a 19GB D: Drive to hardware failure, and proceeded to
attempt restore of the entire filespace from his ADSM Server. We estimate
that there is about 250K files in the filespace, and they are all on tape.
When he does the restore from the NT client, by using the dsmc command:
> dsmc restore -subdir=yes {D921}\*.* D:
there is a brief burst of data from the server to the client (870 bytes, to
be exact) and then the server starts chewing up bunches of CPU on MVS
(30-35%, on average). There is hardly any I/O going on, just CPU. When he
finally cancelled the restore, this had been going on for several hours (4-5
hours at least) with no indication from the server or the client that any
work was being done. We recreated the problem and I monitored the DB buffer
requests, which continually increased over time. This seemed to tell me
that ADSM was doing lots and lots of DB operations, mostly in memory.
We decided to narrow the scope a bit, and just picked one subdirectory for
restore. Again:
> dsmc restore -subdir=yes {D921}\share\mktg\*.* D:
Which should pull back around 100 or so files. This time, the server took
almost 1 hour to decide what files to send. At about T+51 minutes, we
finally got a tape mount request and once the tape was mounted by the 3494,
the files transferred in a matter of seconds. During this test, I also
monitored the db buffer requests. There were about 9 Million buffer hits
during the time that it took to make it's decision to send about 100 files.
This seems to be excessive, as if there is a totally unindexed query just
being tossed to the db.
Now, we tried to force a "classic restore" of the same filespec by using
the -pick option. Total time from start to finish was about 3 minutes
(about 13:1 improvement).
Does this sound right to anybody? I haven't had much experience with
restores of large filespaces in the no-query-restore environment, but this
just seems ludicrous. My understanding of the process is that the server is
sorting the files by volume, to minimize tape mounts. I can't understand why
the MVS server is so slow in doing this.. Response time for other ADSM
operations is very good (subsecond) while the db "chewing" is in progress.
The other thing that makes this seem a bit weird is that the tape storage
pool for this client is collocated. Since that would appear to reduce the
number of volumes to just a few, why is the sort even taking place?
I'm open to any suggestions. We did adjust several server options
(especially the db buffer pool size) to see if there was any effect, but it
didn't seem to matter. I guess we have a potential workaround right now by
using the -pick option and selecting "all", but I'm curious to see if others
have experienced the same thing.
Thanks for your help....
--------------------------------------------------------------
Matt Cleland mcleland AT msiinet DOT com
Matt Cleland mcleland AT msiinet DOT com
IBM Certified Specialist - ADSM
Midland Systems, Inc. (MSI) (618) 345-0864
St. Louis, MO (618) 346-1779 FAX
|
