If your application and business can support using the Oracle Database 10g commit write facility, as described earlier, it could possibly instantly resolve this issue. So seriously yet cautiously consider this option.

If I find that the top one to three wait events is log file sync, I always check the number of group members to see if it can be reduced. When the log writer background process writes to an online redo log group, every member of the group must be written before the write will be complete. Depending on your IO subsystem configuration, it could possibly take a relatively long time for each member to be written. The number of online redo log group members should be set based on availability and recoverability targets, but once those targets are met, do not add any more group members.

As strange as it might seem, decreasing the redo log buffer size can reduce the likelihood of receiving log file sync wait events. Because of the one-third full flush rule, a smaller redo log buffer will force the log writer background process to write more often. These flushes are not the result of commits, but rather the log writer background process being triggered. So when a commit does occur, there is a higher likelihood that all but the commit entry will have already been written to an online redo log group and the commit occurring instantly! However, as you're probably already thinking, if the log buffer is decreased too much, server processes will start posting log buffer space events. If response time is improving, this may be an acceptable compromise. But as always, we need to discover the optimal performance balance.