While the Oracle documentation is not entirely clear, it does seem to indicate global temporary tables do not generate any redo. While my experiments3 showed this to be incorrect, even the worst case scenario achieved a remarkable 43% redo reduction. For example, with a row size of 750 bytes, redo was consistently reduced by 68.1%. And even more important, as the row size increased, so did the redo savings.

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