理解REDO LOG（1） 介质恢复和实例恢复的基本概念
oracle世界，有3种数据：undo、redo和data。而redo 应"提交事务不丢失"而生的一种机制，服务于两类场景：一是instance recovery、一是media recovery。
instance recovery目的：当数据库发生故障时，确保buffer cache中的数据不好丢失，保证数据库的一致性
media recovery 目的：当数据文件发生故障时，能够恢复数据
redo是按照thread来组织的。于单实例，只有一个THREAD；于RAC，可能存在多个THREAD。
redo log机制是私有的：每个实例都有自己的log buffer。但在rac环境，redo log file是共享的。
无论哪种恢复，第一步都是（数据文件的状态）借用redo数据前滚（undo数据文件亦被前滚）直至最后一个可用的redo log或者归档日志。
再者，oracle的cache机制是以性能为导向，绝非存储用的。为了这个目标，oracle须处理两个问题：
1）如何确保提交的事务不丢失？
2）如何均衡实例恢复的时间？
第一个问题：Log-Force-at-Commit机制
commit时写日志，当返回commit complete时，才写完日志，即使返回到“Commit compl”时，突然断电，日志也没有写完。
第二个问题：checkpoint机制
data由server process读上来，但并不负责写下去，buffer cache写操作由DBWn完成，DBWn根据workload以及是否被其他process使用来将一部分数据写到数据文件，这是具有随机性的。而checkpoint机制便是对这种情况的有效补充。发生检查点时，CKPT进程会要求DBWn将某个scn以前的所有dirty buffer写回数据文件。完成一次检查点，这个scn之前的所有数据变更都已经存盘，如果此时发生故障，则这个事件以前的变更就无需考虑。
