Head of the log: Points to where new redo entries are added
Tail of the log: Points to the next redo log entry that needs to be written to disk
113,112,111: Old redo log entries, long since written to disk
903,902,901: Redo log entries that have just recently been written to disk
998,997...906,905: Redo log entries that are waiting to be written to disk
904: This will be the next redo log entry written to the redo log files.
999: This is the most recently added redo log entry.
log writer (LGWR)
The background process responsible for redo log buffer management,writing the redo log buffer to the online redo log. LGWR writes all redo entries that have been copied into the buffer since the last time it wrote.
The log writer process (LGWR) writes redo log entries in the SGA's redo log buffers to the redo log file. It also writes the transaction's SCN to the redo log file. This atomic event constitutes the commit of the transaction.
Note: Sometimes, if more buffer space is needed, LGWR writes redo log entries before a transaction is committed. These entries become permanent only if the transaction is later committed.
(SCN) system change number
When a user commits a transaction, the transaction is assigned a system change number (SCN), which Oracle records along with the transaction's redo entries in the redo log.
SCNs are recorded in the redo log so that recovery operations can be synchronized in Real Application Clusters and distributed databases.
In times of high activity, LGWR can write to the redo log file using group commits. For example, assume that a user commits a transaction. LGWR must write the transaction's redo entries to disk, and as this happens, other users issue COMMIT
statements. However, LGWR cannot write to the redo log file to commit these transactions until it has completed its previous write operation. After the first transaction's entries are written to the redo log file, the entire list of redo entries of
waiting transactions (not yet committed) can be written to disk in one operation, requiring less I/O than do transaction entries handled individually. Therefore, Oracle minimizes disk I/O and maximizes performance of LGWR.
If requests to commit continue at a high rate, then every write (by LGWR) from the redo log buffer can contain multiple commit records.
An atomic transaction is a possibly complex series of actions that is considered as a single operation by those not involved directly in performing the transaction. If you transfer $100 from Alica's
account to Bob's account, no one else can see the database while it is in an intermediate state where the money has been removed from Alice's account and not yet added to Bob's.
The transaction either happens completely or none of its pieces happen and cannot happen partially.
Atomic transactions are important for maintaining consistency and validity, and are thus important for the R and U parts of CRUD.
Physical data containers such as notebooks support atomic transactions because typically only one person at a time can use them. You can finish a series of operations before you let someone else have a turn.
Some of the most primitive kinds of databases, such as flat files and XML files do not inherently support atomic transactions, but the more advanced relational database products do.
Those databases allow you to start a transaction and perform a series of operations.
You can then either commit the transaction to make the changes permanent or rollback the transaction to undo them all and restore the database to the state it previously had, before you started the transaction.
These databases also automatically rollback any transaction that is open if the database halts unexpectedly.