Re: redo log stats

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:978647301.5316.0.nnrp-04.9e984b29_at_news.demon.co.uk... >
> Technically it is a wait for space in the buffer,

Then space requests event occurences are inspired by the server-side user processes. And the worst case number is approx. 'switches x processes'? (But then, hmm, could not some background process (SMON?) also cause this space request event?) Must user process also wait for a complete checkpoint, during log switch (with included dirty buffers completly written by DBWR)?

> but one of the reasons why the buffer runs out
> of space is because a redo log switch is occuring,
> and the time taken too switch is so long (a few
> seconds perhaps) that the redo buffer fills before
> the switch is complete.

Perhaps possible causes for slow motioned log switch: Inadequate disk I/O, way too big redo buffer, unusually heavy redo-generating/commit load, ...
Could take some time to analyze, it seems.

> If the number of space requests is about the
> same as the number of log switches you don't
> have a problem. If it is vastly higher, then you
> may have to consider changing the log buffer
> size.

So one per switch is 'best case' and processes x switches is worst case (having more than a few user processes)?

Regards
/Fad Received on Tue Jan 09 2001 - 17:07:07 CST