In <1995Feb16.173311.20532 AT draper DOT com>, MAINT%PUCC.BITNET AT vm.marist
DOT edu (Melinda Varian) writes:
>Three times in the past month, our VM ADSM server has run out of
>recovery log space, which is not at all a pretty sight. After the
>second occurrence of the problem, I doubled the recovery log space
>from 56M to 112M (200 cylinders of 3380). This kept us going for
>a couple of weeks, but we had the failure again last night.
>
I have had to double the logspace also, twice! I remember running out
once during a migration, but the server waited and I added the
logspace on the fly and then the migration ended (MVS server).
>
>I have a virtual machine that watches over DSMSERV. As the result of
>the first two failures, it has code to do a QUERY LOG every ten minutes.
>I am seeing the percent utilization for the log usually under 2%, but
>every once in a while it goes shooting up to 50% or more. Then, it
>will suddenly drop down to the normal value in one of these 10-minute
>intervals.
>
>My current hypothesis is that the problem is the result of a migration
>from BACKUPPOOL (disk) to tape, but I'm not sure of this. Can anybody
>tell me what ADSM saves in the recovery log during this process? I'm
>guessing it must be an entry for every file that is moved.
>
The recovery log records info about in-flight transactions. A
transaction is one or more files sent from a client during a backup.
And there are undoubtedly transactions going on during
migration. The times I have sent the log get very large are when a
particular client starts up and send a 300 meg file to the server
over appletalk. It takes about 12 hours, and during that time the log
can not commit and clean itself up, so it grows and grows.
Add a 'q ses' to your monitor so you can identify long running
sessions and maybe correlate then with log expansion.
I have not run out of log since I expanded it to 400 cylinders of
3380. (Too bad that there is no tool to serch the database for files
with certain characteristics, like size and arrival date).
>
>We had a migration going yesterday from 15:27 until the log filled up
>at 00:32. During that period, I saw the log utilization bouncing up
>and down. It was 2.8 at 22:42, for example, although it had been much
>higher earlier.
>
>The day before that, we had a migration going from 22:16 to 00:52, but
>the utilization got up to "only" 50.6 percent, starting from 0.5 just
>before the migration began. Between 01:22 and 01:32, it dropped from
>50.4% to 0.4%. I'm not sure that migration was the process involved,
>but there were no other long-running processes.
>
>I'm ready to throw another 100 cylinders at the problem, but I'm not
>at all sure that something pathological isn't going on here. I'm also
>worried that I've lost information (or tapes) as the result of shutting
>the server down after the failures. Advice?
>
>Melinda Varian,
>Princeton University
>
Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
|
