Thanks for your reply. Indeed the transactions parameter is high due to derived value from session which is set to 5000, & cpu is 64. On the public and private strands, public strands equals 16MB (which i set for log_buffer) spread across 4 threads and there are quite a few (about 500+) private strands with nearly 130KB. COMMIT doesn’t need to wait for private strands to be flushed? atleast the ones in use?

I will also actively update on OTN, we can discuss there if you prefer.

Rgds
Abhay

The difference between your setting for the log buffer and the usage you report is a little surprising. Based on the numbers I would guess that you have a machine with quite a lot of CPUs and an instance with a large value for parameter “transactions”.

Rather than guess, though, I would prefer to check the cpu_count and value of the parameter, and I would like to see the number of log buffer strands (public and private) that you have – and there is a query on my blog that SYS can run to report the last one:
http://jonathanlewis.wordpress.com/2012/09/17/private-redo-2/

I see that you’ve also taken this to OTN, and it’s best to continue it there. However, it’s worth pointing out that essentially your comments about big buffers and the mix of long and short transactions resulting in “unreasonable” log file sync waits for the short transactions are correct. When a session issues a commit it has to wait for ALL the public log buffers to be written to disc up to their high water marks, and if you have several buffers which have been filled very rapidly by multiple concurrent batch processes then a session that does one little update and commits may have to wait for several megabytes of redo to be written.

I think Tony Hasler ( http://tonyhasler.wordpress.com/ ) has written a blog note about this; and because LGWR was writing the separate log buffers one after the other (rather than try to write them all asynchronously) his workaround was to disable the multiple log buffer feature.

I note that log_buffer even if set, is going to be different {more} post 10.2.x – however if it (oracle internal algorithm) sets a very high value we can see side effects of too long “LOG FILE SYNC”? In one of our PRD instance, we have a SGA granule size of 64MB and when we set LOG_BUFFER to 16MB, i see redo buffers of more than 78MB. Since we have a mixed workload (short transactions + batch jobs) – short transactions are seeing some waits on log file sync. Earlier log_buffer was set to 150MB and oracle took nearly 210MB the waits seen on short UI house keeping transactions were waiting quite long and after reducing – we are now in a “thin acceptable limit”. Is there any other way to reduce redo buffers? anything less than 32MB not only may be enough it will bring down my log file sync even further (which is very much needed for UI house keeping transactions). Even if i unset, i think its still going to allocate 64MB? BTW, we are on 11.2.0.3.

Rgds
Abhay

I have deleted several comments relating to a non-technical posting by Don Burleson that has since been removed from his website. I have also edited several posts to make them consistent with the other deletions.

If you are the author of a post that I have modified and object to the change I have made, please let me know, and I will either delete the entire post (or apply any alteration that you think fit).