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.

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.