Paul,
I'm not sure that I fully understand this issue regarding a thread having
the recovery log pinned at all. When we had the last crisis as a result
of the log being pinned I was not on hand at the time of the server crash
and so it was difficult afterwards to piece together what might possibly
have happened to cause it. There was evidence of a long running session
and I concluded it may have been implicated - but could not actually prove
that. I now get quite nervous when I spot long running backups (passing
over the 'next DBB INCR') and have tried to observe what happens to the
recovery log utilisation then.
Last week I noticed such a session and curiously when the DBB INCR finished
(as part of our daily houskeeping BKSTG, MIG, DBB) the recovery log reset
to 0.1%. Now as the session was still active it would still be writing to
the recovery log so 0.1% seemed reasonable. But the point is, it did reset.
So I conclude that there may be some additional factor involved when the
log gets pinned? Maybe some error condition that is not handled properly?
[We run in roll-forward mode.]
We first had this problem in 1998 and we don't seem to have made very much
progress in a resolution! Last time I had a PMR on this it was suggested
I put in a design change request (so it must be working as designed now).
Regards, Sheelagh
--
>X-Sender: [EMAIL PROTECTED] (Unverified)
>Mime-Version: 1.0
>Date: Thu, 31 May 2001 12:19:33 -0400
>From: Paul Zarnowski <[EMAIL PROTECTED]>
>Subject: Re: Recovery log utilization does not drop after DB backup
>To: [EMAIL PROTECTED]
>
>We run into this problem a lot. I believe there are a couple of issues
>here. One issue, that Gerhard mentioned, is that the log utilization does
>not drop quickly when the db backup apparently finishes. The other issue
>is that a thread can have the log "pinned", preventing the log utilization
>from dropping. The thread can be a session or a process. A session
>backing up a single large object, or a smaller one over a slower speed
>network, can cause this problem. Also, a process (or session) doing tape
>I/O which has gone into error recovery (which can take hours) can also
>cause this problem. I'm sure there are other situations which can cause a
>pinned log as well. These two problems can lead to several operational
>problems. In addition to the log filling up, if you have triggered db
>backups, they can keep triggering in a loop, quickly using up all the tapes
>allocated for db backups (if you are using tapes).
>
< ... snipped ...>
Sheelagh Treweek
Oxford University Computing Services
Email: [EMAIL PROTECTED]
Phone: +44 (0)1865 273205 Fax:-273275
+---------------------------------------------------------------------+
| http://tsm-symposium.oucs.ox.ac.uk/ OXFORD 20/21 September 2001 |
| REQUIREMENTS http://tsm-symposium.oucs.ox.ac.uk/requirements.html |
+---------------------------------------------------------------------+
