If you have the opportunity to design batch processes, do everyone a favor and consider incorporating global temporary tables. And if you are a performance analyst stuck in a corner with an application generating far more redo than your IO subsystem can hope to adequately process, or a developer needing more memory than a single process can allocate, don't forget about global temporary tables.

The log writer background process's job is to quickly flush the redo log buffer. As with the database writer, multiple events trigger the log writer background process to write. Because Oracle promises that committed transaction information has been written to disk (as far as Oracle knows), the obvious log writer background process requirement is to flush the redo log buffer when a transaction commits. But to keep the redo flowing smoothly and quickly, there are also a number of other events that trigger the log writer background process into action.4

While redo is generated and copied into the redo log buffer as part of DML processing, when a commit is issued, control is not returned to the server process until all of the associated transaction redo has been successfully written to an online redo log group. While the server process is waiting for the log writer to give it control once again, it will post the log file sync wait event. In fact, the average log file sync wait time is a good indication of the average commit time from an Oracle perspective.