1,当进程正在buffer cache pin block数据块进行修改时,进程发生故障dead;
2,即在buffer cache中的block处于不可知状态，可能发生了部分更改；
3,pmon出场则会自disk重新读取block;
  pmon然后扫描在线日志文件及pin block之前产生的log buffer部分,
  并应用扫描到的在线日志文件及log buffer;
  损坏的数据块得到了恢复
 
 
4,对同一个块产生的多次变更,scn相同，但为了区分不同的变更，采用不同的seq

5,redo record针对一个事务概念，而change vector则是一个事务中涉及不同数据块的变更版本
6,redo record基于scn进行排序

7,redo record的结构

              --rba标识redo record在redo log file中的位置
REDO RECORD - Thread:1 RBA: 0x0000bd.00000226.0010 LEN: 0x02dc VLD: 0x0d

---scn标识redo record产生时的scn
SCN: 0x0000.00599125 SUBSCN:  1 04/18/2013 10:01:59 

8，redo与thread有关
   redo与thread的关系存储在控制文件的redo log file record及redo thread progress中

9,thread即产生redo的实例我更多把它理解为产生redo的进程，一种动态
  一般情况就一个thread,而在rac会出现多个thread
 
10,checkpoint检查点与redo文件
   checkpoint让redo file可以重用即redo file实现环式循环使用的基础机制
  
11,增量检查点自oracle8i引入;
   之前进行完全检查点，每次发生检查点事件,把buffer cache中的所有脏数据全部写入data file,这样io压力很大；
   增量检查点通过引入checkpoint queue机制，每一个dirty block以low rba（首次对数据块修改）存储在checkpoint queue中，
   发生增量检查点时,ckpt通知dbwr自checkpoint queue把脏数据写入到数据文件中
   靠近checkpoint queue的尾部是最小或最老的low rba，而且对同一个数据块多次变化不会改变它在checkpoint queue中的位置，这样就会保证最早改变的数据块最先写入到数据文件中
  
    
增量检查点（incremental checkpoint）
    oracle8以后推出了incremental checkpoint的机制，在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，
    巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，
    按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，
    而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。
    每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。   
   
增量检查点   
 应该是只更新控制文件，每3秒不是更新数据文件
 1，增量检查点仅更新控制文件，每3秒哟
 2，增量检查点不更新数据文件
 3,用于实例节省恢复时间
 4,增量检查点时ckpt告知dbwr要写入在checkpoint queue中的最新写入结束的位置;
   在控制文件就记录这个最新写入结束的位置
   这样实例恢复时不是从数据文件checkpoint scn开始，而是从控制文件最新的checkpoint queue scn开始，就减少了恢复时间
   此时控制文件最新的checkpoint queue scn要新于或大于数据文件的checkpoint scn
 5,每次发生检查点事件，ckpt更新数据文件头和控制文件，不是把当前发生检查点的scn更新到数据文件头及控制文件
   而是把上次dbwr写入diry buffer已完成的检查点scn写入到数据文件头和控制文件