Yes, your COMMIT rate is too high and forcing LGWR to be overactive. If you can cut down on the commit frequency, then you will probably get a pleasant performance boost during those times of peak redo generation.

Thanks for the tip. Here is what I gathered and calculated based upon statistics from the V$SYSSTAT:

Stat#   Name                                                 Value
-----   ----------------------------------------   ---------------
91      redo writes                                      1,004,867
92      redo blocks written                             69,132,466

redo blocks written/redo writes = 69132433/1004867 ~ 69 blocks = 35,328 bytes

As I had stated earlier, the log buffer size for this database is 1M. If LGWR writing threshold is 1/3 of the log buffer size, then from this definition the LGWR should write after 1048576/3 ~ 349,526 or 682 blocks. This number is almost 10 times larger than the actual number I am getting from V$SYSSTAT. This is a data warehouse running on Oracle 7344. The redo logs are 400M per piece. Majority of the load is done via SQL*Loader (direct path mostly), some via a third party tool (data stage) and the rest via sql and pl/sql scripts. Under peak load conditions the log switches after 2.5 - 3 minutes. Does this mean that users are committing too often (in their sql/plsql scripts) and that is why the LGWR is flushing the buffers to log files even before the log buffer is getting 1/3 filled up?

Generate some redo intensively, and watch the redo writes and redo blocks written statistics in V$SYSSTAT.

A small change to my previous calculations, I should see a value of (1048576/512)*1/3 ~ 683

I was wondering how to check the existing setting of _log_io_size parameter. I understand that by default it is set to 1/3 times log buffer size. My current log buffer size is 1M and I am running on Sun Solaris 2.6, therefore, the redo log block size is 512 bytes (I confirmed it from X$KCCLE.LEBSZ column) and so I should see a value of 2048 (1048576/512) hidden somewhere.