实例崩溃恢复原理--检查点队列的作用

实例崩溃恢复原理

　　数据库中存在着buffercache，buffercache有很多的块，其中包括脏块

　　数据库运行期间有很多的脏块，这些脏块是还未写入磁盘，这时，如果数据库存在的服务器突然断电死机，出现故障，这些未写入磁盘的脏块的数据就会丢失。

　　数据丢失分为两种情况

　　　　1.可以丢失的数据

　　　　　　对于Oracle数据库来讲，未提交的事务所修改的数据块可以丢失

　　　　2.不可以丢失的数据

　　　　　　已经提交的事务所对应的数据块不可以丢失

　　数据崩溃的瞬间，这两种脏块时都存在的

　　Oracle崩溃以后，有些数据是要通过日志来找回的

　　数据库崩溃瞬间，块类型包括：

　　　　1.脏块对应的日志已经写入磁盘------说明块对应的事务已经提交，可以通过日志将脏块构造出来

　　　　2.脏块对应的日志在logbuffer中-----说明块对应的修改了的事务还未提交，对于数据库来讲，说明这个块是可以丢失的。丢失的话，也就意味着对于数据的修改没有进行

　　数据库非正常关闭的情况下，是要启动实例崩溃恢复的

实例崩溃恢复

　　使用磁盘上的日志，将数据库崩溃的瞬间所对应的脏块构造出来，也就是说，将buffercache恢复到了数据库崩溃的瞬间。

　　Oracle使用日志恢复的时候，只能恢复到磁盘上的最后一个日志

　　Oracle数据库非正常关闭或者服务器死机，断电等等一些原因导致oracle实例崩溃。导致脏块丢失，Oracle就可以使用redolog里面的日志将我们所有需要的脏块构造出来。

实例恢复时，会用到哪些日志呢？日志的起点与终点

　　redolog中的日志，使用到最后一条，将所有日志跑完，

　　终点是current日志的最后一条，问题是起点是谁呢？

　　起点：LRBA地址

实例崩溃恢复的过程：

　　　　　　1.Oracle发现数据库实例关闭崩溃，需要做实例恢复

　　　　　　2.Oracle在控制文件中找到检查点队列的LRBA地址，根据LRBA地址找到日志起点，从日志起点跑到日志终点，整个过程中，Oracle中已经提交事务的脏块以及未提交事务的脏块全被构造出来，而未提交的事务已经在undo中进行记录了。

　　　　Oracle在此后的操作中，会自动将崩溃前未提交事务，自动进行回滚。

　　　　前滚----跑日志，将丢失脏块构造出来

　　　　回滚----会自动将崩溃前未提交事务，自动进行回滚。

检查点队列的作用：

　　　　　　　　1.确定日志起点

　　　　　　　　2.加快Oracle数据库实例崩溃恢复速度