In this chapter, we investigated how to measure redo. We also looked at the impact that NOLOGGING has on redo generation.

When used in combination with direct path operations (e.g., direct path insert), the generation of redo can be reduced dramatically. However, for regular DML statements, the NOLOGGING clause has no effect.

We explored the reasons why a log switch might be delayed. Oracle won’t allow a redo log to be overwritten in the event that DBWn has not yet finished checkpointing the data protected by the redo log or ARCn has not finished copying the redo log file to the archive destination.

This is mainly a problem for the DBA to detect (inspect the alert. log) and manage.

We discussed how redo is handled with transactions that occur in temporary tables. In 12c and above, the amount of redo can be reduced to nearly nothing.

For applications that use temporary tables, this can have a positive impact on performance.

In this chapter, we also investigated which statements generate the least and most undo. In general, an INSERT generates the least amount, an UPDATE generates more than INSERT, and a DELETE generates the most undo.

Lastly, we explored the causes of the infamous ORA-01555 error (snapshot too old).
This error can occur because the undo tablespace has been sized too small.
The DBA must ensure that the undo tablespace is sized large enough mostly to eliminate this as a cause for the error. We also looked at how a delayed block cleanout can cause issues.
If you’ve correctly sized your transactions and your undo tablespace, you will probably rarely run into this error.
Tuning the query that throws the ORA-01555 error should always be one of the first methods employed to resolve the issue.