实例崩溃恢复原理
数据库中存在着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数据库实例崩溃恢复速度