Gretchen,
some time ago I had the problem that the log utilization was not reset after
a db backup. In this case the support center recommended to use the
undocumented ckpt command which worked as a temporary bypass.
I strongly recommend to open a severity 2 pmr and ask the support center
what to do.
Thank you very much for sharing your experiences with us. Please tell us
when you have additional information.

Why can the hardware people build reliable devices whereas the software
building art is in such a bad state?

Best regards
Gerhard
---
Gerhard Rentschler            email:g.rentschler AT rus.uni-stuttgart DOT de
Regional Computing Center     tel.   ++49/711/685 5806
University of Stuttgart       fax:   ++49/711/682357
Allmandring 30a
D 70550
Stuttgart
Germany



> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Gretchen L. Thiele
> Sent: Monday, February 10, 2003 3:03 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: v5.1.6.1, so far
>
>
> The two situations where I could force a core dump in v5.1.6.0 have
> been resolved, but I think there is now a different problem in
> v5.1.6.1.
>
> Granted, my servers run flat out all the time with sessions constantly,
> but I rarely pin the 13 GB log with dirty pages (at least not over
> 60 to 70%). It's happening all the time now. I've had to cut back
> on my workload by two thirds in order to get the log to settle down.
> Not good. It took out two of my servers a couple of times over the
> weekend until I severely limited the number of sessions and scheduled
> sessions.
>
> The log would creep up and I'd get the 'log is pinned by a dirty
> page' from 'show logpin'. When the log started to cool off, but not
> drop in utilization, this message would alternate with the 'log
> not pinned, will be cleared at next commit'. It took one server
> over 5 hours last night to 'calm down' - I disabled sessions when
> it hit 40% and it climbed to over 80% before it started to wane.
>
> Also, when it's a client that has the log throttled, it's almost
> impossible to cancel the session before the log fills and core
> dumps the server. A 'cancel session force=yes' would be really
> nice about now. It's about a wash whether or not to allow the
> log to fill and core dump or just halt the server and let it
> come up again and 'figure' things out.
>
> It'd be nice to know if we can force a commit or if it's time
> based, just when does it happen?
>
> Gretchen Thiele
> Princeton University