Matt,
We are running ADSM server V3.1.2,0 on OS390 V2.4 and we are facing the same
kind of problem with the NT 3.1.1,5 and 3.1.1,6 client codes: The restore of
a small subdir containing about 10 files occurs following this scenario:
Client asks restore via the graphical interface. He is asking the last
version of the files. ADSM executes a "no query restore".
Client is waiting for 35 minutes before the server begins to transfer data.
On the client side, the status of the session is "Waiting for files"
On the Server side, the satus of the session is "Running".
But nothing moves. I've not looked to the DB cache activity at this time.
After the 35 minutes "waiting", the cartridge is mounted and the data
tranferred in 1 or 2 minutes.
It looks like your problem.
PMR 39062 is opened until 1 OCT 1998, 4 different traces are be sended to
the lab and we are waiting {..... more than 35 minutes (joke)}.
Happy to share experience with OS/390 - ADSM users.
Francis.
_______________________________________________________________________
Francis Maes ASLK-CGER Services GIE - Belgium
ADSM Server Administrator Rue Fossé-aux-Loups, 48 - 1000 Brussels
Storage Management E@Mail: fr.maes AT cger DOT be
-----Message d'origine-----
De : Matt Cleland <adsmrus AT bigbrowndog DOT com>
De : Matt Cleland <adsmrus AT bigbrowndog DOT com>
À : ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
Date : mardi 5 janv. 1999 15:59
Objet : Extended Restore times for no-query restore on MVS
>I'm resending this, as it went out over the holiday and I got no
response...
>
>---------------------------------------------------------------------------
-
-
>
>
>
>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
>IBM Certified Specialist - ADSM
>Midland Systems, Inc. (MSI) (618) 345-0864
>St. Louis, MO (618) 346-1779 FAX
>
|
