Comments in-line.
--
Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
Practical Oracle 8i: Building Efficient Databases
Publishers: Addison-Wesley
See a first review at:
http://www.ixora.com.au/resources/index.htm#practical_8i
More reviews at: http://www.jlcomp.demon.co.uk/book_rev.html
Taki P wrote in message ...
>
>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)?
No - a 'reasonable' number is approx:
'switches x typical number of concurrent transactions'
a 'slightly surprising' number would be:
'switches x concurrent processes'
A worst case could be very high - this typically
would be caused by having log_buffer too small.
User processes do not wait for the checkpoint to
complete, the wait at this point is simply for
Oracle to finish writing the old redo log and
open the file for the new redo log. This can
actually take a small number of seconds (see
Steve Adams website and book).
>
>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.
Having a too big redo buffer is more likely to lead to high
values in v$session_wait for 'log sync' and 'log write'.
>
>> 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)?
>
I made an error in the above - I should have said:
>> If the number of space requests is about the
>> same as the number of log switches X
>> typical number of concurrent transactions ...
Received on Tue Jan 09 2001 - 18:11:43 CST
