Hi Paul, The parameter you are looking for is probably _log_io_size (see http://www.ixora.com.au/tips/tuning/log_buffer_size.htm), but I doubt it can help you. One of the reasons is that IO is fragmented also at the OS (solaris >=8 default to 1 MB if I am not wrong) and HW (storage array) level. Tuning to reduce the redo log volume or changing the physical device where you write the redo logs (like avoid raid5, avoid Read/Write contention, ..the usual stuff) is normally the way to go for this kind of issues. You can also recreate the redo logs in /tmp (ram disk), but that's a bit 'dangerous' and also kind of cheating. Regards, L. ----------- Luca Canali Information Technology Department European Organization for Nuclear Research CERN CH-1211 Geneva 23 -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Paul van den Bogaard Sent: Tuesday, February 14, 2006 5:10 PM To: oracle-l@xxxxxxxxxxxxx Subject: LGWR tuning During a previous benchmark I learned that the LGWR will chop writes into chunks of max 1MB. This results in multiple AIO send to the Solaris kernel in quick succession. The transactions were throttled by 'log file sync' event. Another benchmark will occurr that drives this application to even higher limits. I wonder/expect there is a (hidden) parameter that resets this 1MB limit to something more appropriate. Any clues how this parameter is called and should be set are very welcome. HInts on side effects that come for free are welcome too :-) Thanks Paul Redo files are on raw devices. A single redo file is mapped on one or more disk arrays (through host based volume management) that each have lots of memory backed up cache. Average write time expected to be in the sub milli second level. -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l