Oracle原理(实例恢复)

实例恢复

 

数据库正常运行期间，在每个完全检查点时，检查点进程（CKPT）都会触发数据库写进程（DBWn）以保证将所有已提交的数据块都能从内存及时写入数据文件并刷新数据文件头。

另外，在比如 shutdown immediate 正常关机情况下，系统会在关机命令执行的时间点（非完全检查点）执行强制检查点过程来保证将内存中提交过的所有数据块写入数据文件并刷新数据文件头，这种情况也确保了数据库的一致性，表示没有数据丢失。

但是在实例意外崩溃或紧急关机过程中，由于没有执行强制检查点，因此导致内存中大量提交过的数据块没有写入数据文件，同时数据文件头也没有刷新，那么下次数据库重启时，在 open 阶段，系统监视器进程（SMON）在根据控制文件的记录打开每一个数据文件时就会发现数据库没有同步过，这时 SMON 会自动执行实例恢复，以把丢失的内存中数据库的修改重新找回来。

实例恢复包括了前滚和回退两个阶段。前滚阶段，SMON 打开每个数据文件时会记录该文件头已同步过的 SCN 值，在全部数据文件都打开后，SMON 用已同步过的最小的 SCN 值在联机重做日志文件中逆向匹配，找到包含该 SCN 的第一条重做条目，然后从下一个 SCN 的第一条重做条目开始，把每一条重做记录所对应的事务都重新执行一遍，一直到重做日志文件结尾。增量检查点机制会对前滚操作进行优化以提高前滚的效率。现在，数据文件里就包含了截止到故障点的所有已提交和未提交的数据库修改，但是未提交的更改是不应该写入到数据库的。出现这个情况的原因在于重做条目是在事务开始执行时就产生了，但是同时开始执行的事务不一定同时结束，那些跨故障点的事务虽然没有提交，但重做条目在事务开始执行时就已经按顺序写入重做日志缓冲区并很快写入联机重做日志文件组。

在回退阶段，以只读方式打开数据库，对所有前滚过的重做条目重新检查一边，凡是提交状态的 SCN 和时间戳为空的条目，把该条目前滚时所产生的还原数据从还原段读出直接覆盖数据文件相对应的块，同时修改相应的元数据，最后把数据库状态改为读写方式。至此，数据库中就只包含了截止到故障点的所以已提交过的数据库的修改。自动的实例恢复执行完成，用户就可以正常执行事务了