ADSM-L

Re: Extended Restore times for no-query restore on MVS

1999-01-06 04:18:41
Subject: Re: Extended Restore times for no-query restore on MVS
From: Francis Maes <fr.maes AT CGER DOT BE>
Date: Wed, 6 Jan 1999 10:18:41 +0100
Matt,

Our DB size is 46GB,
it references 55.000.000 backup and archive versions plus copy in copygroup
and about 5 TB of backup and archive data.
current utilization 87%
Cache hit 97,55% to 99%
Bufferpoolsize 71680 ! upgraded from 32768 by steps of 10240 in parallel
with DB growing.

In our environment, a 50 GB DB seems to be à maximum.
The weekly full backup running on sunday takes about 7 hours for a 46GB DB.
More would be too much.
Due to the fact the client's data are still growing, we plan to start a
second ADSM MVS server.

Expire invetory is running on the week days and takes daily about 3 hours.
Tape reclamation is running on saturday for the backup and copy pools.
We are using an STK Powderhorn robot with Timberline drives.

Best regards,

Francis.





-----Message d'origine-----
De : Matt Cleland <adsmrus AT bigbrowndog DOT com>
De : Matt Cleland <adsmrus AT bigbrowndog DOT com>
À : Francis Maes <fr.maes AT cger DOT be>
Cc : ADSM-L <ADSM-L AT VM.MARIST DOT EDU>
Date : mardi 5 janv. 1999 22:19
Objet : RE: Extended Restore times for no-query restore on MVS


>Hi Francis:
>
>This sounds exactly the same as the behavior we are seeing.  If you were to
>look at the db buffer cache hits during the long wait time, you would see
>them continue to increase to huge numbers.  Like you said, once it decides
>what data to send, the tape gets mounted and the data comes down in a
matter
>of seconds.
>
>I would be curious to know what your BUFPOOLSIZE is set to on the server.
>The tuning guide recommends 32768 for MVS servers, but even with that we
>were only seeing cache hit ratios in the 98% range.
>
>Thanks for your response!
>
>--------------------------------------------------------------
>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
>
>
>> -----Original Message-----
>> From: Francis Maes [mailto:fr.maes AT cger DOT be]
>> Sent: Tuesday, January 05, 1999 9:36 AM
>> To: ADSM questions à la liste; adsmrus AT bigbrowndog DOT com
>> Subject: Re: Extended Restore times for no-query restore on MVS
>>
>>
>> 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>
>> À : 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
>> >
>>
>
>
<Prev in Thread] Current Thread [Next in Thread>