关于Commit和Redo

Database buffers in the buffer cache in the SGA are written to disk only when
necessary, using a least-recently-used (LRU) algorithm. Because of the way that the
database writer process uses this algorithm to write database buffers to datafiles,
datafiles could contain some data blocks modified by uncommitted transactions and
some data blocks missing changes from committed transactions.
　
Oracle 只在必要时依据最近最少使用（least-recently-used，LRU）算法将 SGA
数据库缓存（buffer cache）内的缓冲数据写入磁盘。由于数据库写进程
（database writer process）将数据缓冲区（database buffer）写入数据文件时遵
照上述规则，被未提交事务修改过的数据块也有可能会被写入数据文件，而
被已提交事务修改过的数据块则有可能不在数据文件中。
　
143 Two potential problems can result if an instance failure occurs:
● Data blocks modified by a transaction might not be written to the datafiles at
commit time and might only appear in the redo log. Therefore, the redo log
contains changes that must be reapplied to the database during recovery.
● After the roll forward phase, the datafiles could contain changes that had not
been committed at the time of the failure. These uncommitted changes must be
rolled back to ensure transactional consistency. These changes were either
saved to the datafiles before the failure, or introduced during the roll forward
phase.
发生实例故障（instance failure）时存在两种潜在的问题：
● 被某个事务修改过的数据块在事务提交时可能还没有被写入数据文
件，修改信息只存在于重做日志（redo log）中。因此，重做日志中的
修改信息在恢复（recover）数据库时需要重新应用到数据文件中。
● 在执行了前滚（roll forward）操作后，数据文件中可能会包含实例故障
发生时还未提交的修改。这些未提交事务必须被回滚（roll back）以保
证事务一致性（transactional consistency）。这些未提交事务可能是在实
例故障发生前被写入数据文件的，也可能是在执行前滚被写入数据文
件的。
To solve this dilemma, two separate steps are generally used by Oracle for a successful
recovery of a system failure: rolling forward with the redo log (cache recovery) and
rolling back with the rollback or undo segments (transaction recovery).

为解决上述两个问题，Oracle 需要分两步对系统故障进行恢复。首先利用重
做日志进行前滚操作，即缓存恢复（cache recovery）；之后利用回滚段
（rollback segment）或还原段（undo segment）进行回滚操作，即事务恢复
（transaction recovery）。