Oracle 重做（Redo）日志介绍

1. Redo的作用

Oracle通过 Redo 来保证数据库的事务可以被重演，从而使得在故障之后，数据可以被 恢复。Redo对于Oracle 数据库来说至关重要。本文地址：http://blog.csdn.net/sunansheng/article/details/51918724

在数据库中，Redo的功能主要通过 3 个组件来实现：Redo Log Buffer、LGWR 后台进程 和Redo Log File（在归档模式下，Redo Log File 最终会写出为归档日志文件）。 在Oracle的SGA 中，存在一块共享内存，称为 Redo Log Buffer.

Redo Log Buffer 位于SGA 之中，是一块循环使用的内存区域，其中保存数据库变更的 相关信息。这些信息以重做条目（Redo Entries ）形式存储（Redo Entries 也经常被称为 Redo Records）。Redo Entries 包含重构、重做数据库变更的重要信息，这些变更包括 INSERT、 UPDATE、DELETE 、CREATE 、ALTER 或者DROP等。在必要的时候 Redo Entries 被用于数据库 恢复。

Redo Entries 的内容被 Oracle 数据库进程从用户的内存空间复制到SGA 中的Redo Log Buffer 之中。Redo Entries 在内存中占用连续的顺序空间，由于Redo Log Buffer 是循环使 用的，Oracle 通过一个后台进程 LGWR 不断地把 Redo Log Buffer 的内容写出到 Redo Log File 中。

当用户在Buffer Cache 中修改数据时，Oracle 并不会立即将修改数据写出到数据文件 上，因为那样做效率会很低，到目前为止，计算机系统中最繁忙的部分是磁盘的 I/O 操作， Oracle这样做的目的是为了减少 IO 的次数，当修改过的数据达到一定数量之后，可以进行 高效地批量写出。

大部分传统数据库（当然包括 Oracle ）在处理数据修改时都遵循 no-force-at-commit 策略。也就是说，在提交时并不强制写。那么为了保证数据在数据库发生故障时（例如断电） 可以恢复，Oracle 引入了 Redo 机制，通过连续的、顺序的日志条目的写出将随机的、分散 的数据块的写出推延。这个推延使得数据的写出可以获得批量效应的性能提升。

同Redo Log Buffer 类似，Redo Log File 也是循环使用的，Oracle 允许使用最少两个 日志组。缺省情况下，数据库创建时会建立 3 个日志组。

SQL> select group#,members,status from v$log; 
    GROUP#    MEMBERS STATUS
---------- ---------- ----------------
         1          1 INACTIVE
         2          1 INACTIVE
         3          1 CURRENT
         4          1 INACTIVE

当一个日志文件写满之后，会切换到另外一个日志文件，这个切换过程称为Log Switch 。 Log Switch 会触发一个检查点，促使 DBWR 进程将写满的日志文件保护的变更数据写回到数 据库。在检查点完成之前，日志文件是不能够被重用的。

由于Redo机制对于数据的保护，当数据库发生故障时，Oracle就可以通过 Redo重演进 行数据恢复。那么一个非常重要的问题是，恢复应该从何处开始呢？

如果读取的Redo 过多，那么必然导致恢复的时间过长，在生产环境中，我们必需保证恢 复时间要尽量得短。Oracle 通过检查点（Checkpoint ）来缩减恢复时间。检查点只是一个数据库事件，它存在的根本意义在于减少恢复时间。 当检查点发生时（此时的 SCN 被称为Checkpoint SCN ）Oracle会通知 DBWR进程，把修 改过的数据，也就是此 Checkpoint SCN 之前的脏数据（Dirty Buffer ）从 Buffer Cache 写 入磁盘，在检查点完成后 CKPT进程会相应地更新控制文件和数据文件头，记录检查点信息， 标识变更。

在检查点完成之后，此检查点之前修改过的数据都已经写回磁盘，重做日志文件中的相 应重做记录对于崩溃/实例恢复不再有用。如果此后数据库崩溃，那么恢复只需要从最后一次 完成的检查点开始恢复即可。如果数据库运行在归档模式（所有生产数据库，都建议运行在 归档模式），日志文件在重用之前必须写出到归档日志文件，归档日志在介质恢复时可以用来 恢复数据库故障。