Re: log_buffer parameter size

A copy of this was sent to tonteldoos_at_my-deja.com (if that email address didn't require changing) On Thu, 01 Jul 1999 00:45:11 GMT, you wrote:

>Current database size of 250 GB.
>
>Solaris 2.5/ Oracle 7.3.4 - 20 CPU (E10K) - 20 GB main memory;
>
>We are using four 50 MB on-line red-log files.
>
>Database are very high on-line transaction intensive.
>
>Current setting for log_buffer = 2MB.
>
>If I select from v$sysstat where 'redo log space request';
>
>I get a value back of 6 450! Can anybody recommend the size of the
>log_buffer? Is it dangerous to increase it to 5MB for example? We got
>more than anouth physical memory availible!
>

This stat is the number of times that the background was requested to allocate space in the redo file.

This gives an indication of how many times a user process waited for space in the redo logs.

This is NOT waiting for space in the redo buffer or for LGWR to finish doing a write. The only way to get more disk space is to do a log switch. However this is slightly different from a log switch request in that another process may have already switched the logs and we do not want to do it again.

You need to reconfigure your logging. on such a big machine, 200meg of log isn't very much at all. You might consider adding *lots* more log.

• are you getting "checkpoint not completes, cannot allocate new log" in your alert? If so, we need to get rid of them. either make your log files bigger and set your log_ init.ora parameters so that checkpoints only occurr on log switches or simply add more online redo log files.
• make logging faster. make it so we can write to these files better. are they on a dedicated device? is there contention between lgwr and arch?
• are you using cooked UFS files? if so, you might consider setting forcedirectio on your log disks. this bypasses the overhead of the unix buffer cache (we need to flush to disk anyhow).

among other things. increasing your log buffer *won't* affect this wait event.

>Thanks Tontel.
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.

--
See http://govt.us.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Thu Jul 01 1999 - 06:59:33 CDT