While this sounds simple enough, for recovery reasons, the archive logs may have all sorts of recoverability requirements that significantly slow their archiving. For example, the archived redo log devices may be mirrored, the archived redo logs may need to be written directly to tape (very rare these days), to network-attached storage (NAS), or any number of strategies build to meet recovery requirements.

If slowing down the redo log group switching is still not working, you may need to work closely and cautiously with the recovery team to increase archiving performance. If a solution focusing on increasing archiving IO capacity cannot be found, then the solution focus will have to switch to reducing Oracle redo requirements as presented in the preceding section about the log file parallel write wait event.

Oracle redo is pure overhead, but it's this overhead that enables all sorts of advanced recovery options like point-in-time, table-level, system change number (SCN), and transaction-level. Ensuring this overhead does not negatively impact performance can be challenging at times. Fortunately, the redo process is fairly straightforward (create redo, allocate space, copy the redo, write the redo). and there are a number of very specific wait events. And on top of this, there are a number of advanced Oracle features directly created to deal with unique redo requirements. Redo-related performance issues can be especially tense because they are usually deeply application and IO subsystem related. Making changes to the application and the IO subsystem is something no one desires, but if Oracle's redo requirements are exceeding the capacity of the IO subsystem, sometimes all three perspectives must be intimately involved with solving the problem.