Have you played around with the size and number of your redo logs? Larger redo logs would mean fewer checkpoints.
Dropping redo log member mirrors is tempting, but RAID alone isn't enough protection. I experienced a corrupted file system one time, and I was glad that my redo logs were multiplexed on another file system. >>> [EMAIL PROTECTED] 09/18/02 03:39PM >>> well if you have mirrored members that exist on the same disk thats an issue, if this same disk houses the currently used datafiles that would add to the situation. I placed my redo on a seperate raid-1 and dropped the member mirrors and see better stats. I have a buffer size 1mb but I am using 11i applications. Also consider your log file sizes, the larger the more it has to flush at a given time, but the smaller the more often it has to flush.... all theses consideration above need to be configured according to what you have available hardware-wise. HTH -----Original Message----- Sent: Wednesday, September 18, 2002 1:09 PM To: Multiple recipients of list ORACLE-L We have a canned package that we use to insert approx 100 records/second into one table (oltp environment). Each record is just under 1K (datatypes = number and varchar). There are several indexes that are build on the table as the records are inserted. Each and every record is committed. Therefore we are flushing the 'redo log buffer' to disk (online redo logfiles) 100 times per second (once per commit). Not surprisingly we have noticed IO waits which we believe are associated with our 'Redo Log buffer'. Namely ; log_file_sync = 180 waits/sec log_file_parallel_write = 180 waits/sec We tried resizing the 'redo log buffer' from 16K to 256K - but we did not notice any improvements. Neither Log switching or archiving seem to be excessive. 100 records per second seems to be our maximum speed without the application queuing up and Oracle showing very high waits on log_file_sync and log_file_parallel_writes. Does anyone know how we might be able to minimize the IO waits? Thanks in advance. ENVIRONMENT oracle : Oracle 8.1.7.4 os : Sun Sparc Solaris 8 box : 8x8 E10K IO : Hitachi SANS unit through fiber and Brocade switch _________________________ Patrick J. Howe -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Pat Howe INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). **DISCLAIMER This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jay Hostetter INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
