AW: RE: log_buffer 10gr2

From: Martin Berger <>
Date: Thu, 28 May 2009 16:37:50 +0200
Message-ID: <>

If you can not change the commit frequency, maybe tweaking COMMIT_WRITE can help? ( at least for a little bit )

Best regards,

  • Ursprüngliche Nachricht ----- Von: Bobak, Mark <> Gesendet: Donnerstag, 28. Mai 2009 16:11 An: Cary Millsap <>; <> Cc: Oracle Discussion List <> Betreff: RE: log_buffer 10gr2

Cary read my mind.  The problem is almost certainly related to commit frequency.  Excessive commits will *kill* performance and scalability.  
From: Cary Millsap []  Sent: Thursday, May 28, 2009 10:09 AM
 Cc: Bobak, Mark; Oracle Discussion List  Subject: Re: log_buffer 10gr2
Does the application need to be committing as often as it does?

 Cary Millsap
 Method R Corporation 

On Thu, May 28, 2009 at 8:55 AM, Ujang Jaenudin <> wrote: bobak,

 log file sync is the main reason.
 _log_io_size is 0 (default??)

 strength on my db when user session only 200 but log file sync can  reach 800 session waitings (from dbconsole). when checking the io log  file parallel write max is 4ms, but log file sync can reach 22ms.

 average redo blocks per write is 13 which means average buffer to  write to redolog buffer is only 6656 nytes.

 yes the application is heavily commit activites (now in the "load  testing" stage)

 any direction why too many spikes (strange) on log file sync?

 thanks and regards
 ujang | oracle dba | mysql dba

On Thu, May 28, 2009 at 8:49 PM, Bobak, Mark <> wrote:
> Ok, first, take a step back.
> What is motivating you to look at log_buffer in the first place?  Why do you think it needs to be adjusted?  Starting w/ 10g, the log_buffer is maintained by Oracle, and should not need to be adjusted.  (See MetaLink Doc ID 351857.1.)  What is the current value of _log_io_size?  Why do you think you need to adjust it?
> Main question:
> What is it that is leading you to believe that log_buffer and _log_io_size need to be adjusted?
> -Mark
> -----Original Message-----
> From:

[Die ursprüngliche Nachricht wird nicht vollständig eingefügt.]

Received on Thu May 28 2009 - 09:37:50 CDT

Original text of this message