Because all relational databases (RDBMS) contains, by definition, a transaction log (most of the time based on the [ARIES algorithm [Algorithms for Recovery and Isolation Exploiting Semantics]]), the log, which is a binary file, is divided into three parts, sequentially:
Redo log files occur in two types:[1] Before a user receives a "Commit complete" message, the system must first successfully write the new or changed data to a redo log file.
The RDBMS first writes all changes included in the transaction into the log buffer in the System Global Area (SGA).
[5] If a database crashes, the recovery process has to apply all transactions, both uncommitted as well as committed, to the data-files on disk, using the information in the redo log files.
The system thus re-creates committed transactions by applying the “after image” records in the redo log files to the database, and undoes incomplete transactions by using the "before image" records in the undo tablespace.
The existence of a detailed series of individually logged transactions and actions provides the basis of several data-management enhancements such as Oracle Flashback, log-mining and point-in-time recovery.
For database tuning purposes, efficiently coping with redo logs requires plentiful and fast-access disk.