commit和checkpoint之间的关系

做rman恢复的过程中碰到了一个小疑问

在user表空间创建一个表，

create table t(id int) tablespace users

插入一条数据

insert into t values(1);

commit;

这个时候做一次数据库的全备

backup database;

删除users表空间对应的数据文件，此时再向表t插入数据

insert into t values(2);

commmit;

依然可以插入，提交。

以前老是以为commit就代表把baffer cache中的脏数据块写入到数据文件，其实是不对的

DBWR是由ckpt来触发的，和commit并没有直接的关系，所以这里虽然数据文件被删掉了，依然可以对表做操作

只是

下面是一个解释

checkpoint和commit没什么关系

checkpoint是为了保证数据一致性，在下面情况下触发写事件

a.手工checkpoint, alter system checkpoint;

b.alter tablespace offline/begin backup;

c.正常shutdown 数据库，比如说shudown immediate

写事件就是说他会将数据文件头和控制文件写入同一个id(这里我理解的id其实就是scn号),以便在数据库打开时，通过id知道数据库是否需要恢复，而commit只是当数据文件提交后，触发将redo buffer写入redol file的事件，从而能在恢复时用到日志文件内容，也就是说commit之后没有写入到datafile,如果insert一条数据没有执行检查点，并且recover的时候没有redo log,那么这条数据将不能恢复

ckpt,lgwr,dbwn之间的协作

ckpt:每隔三秒或更频繁写一次，写入控制文件，记录dbwn从sga写入磁盘的快得位置

lgwr:每3秒,1/3满buffer,commit,dbwn写之前。将buffer中数据写入物理文件

dbwn:将sga中的脏块写入datafile

 Oracle 写入数据过程：

Oracle 写数据过程：dml操作一执行，首先在redo buffer中记录语句，在buffer cache中执行更改，修改数据块。然后LGWR进程根据上述规则，将redo buffer中的信息写入到物理文件。此过程比较快（redo log为连续写）。完成后，DBWN会将buffer cache中脏数据块对应的原始数据，复制到undo表空间，然后更新数据。（随机写，比较慢）。期间ckpt进程根据3秒的原则，作检查点，记录哪些脏 数据库写到了data file中（这里的检查点为增量检查点，并不是完全将脏数据写完，只是在控制文件中记录写到哪里了。）。将需要的信息记录在控制文件中。若实例崩溃或需要 错误恢复，从检查点位置以后的redo需要重新应用到datafile（常说的redo过程，前滚）。此时根据事务是否提交了，未提交的事务，根据 undo表空间的数据进行恢复（常说的undo，后滚操作）

 另一位网友的介绍：

1、事务开始；

2、在buffer cache中找到需要的数据块，如果没有找到，则从数据文件中载入buffer cache中；

3、事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中；

4、事务提交，LGWR进程将log buffer中的“脏数据”写入redo log file中；

5、当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。

 

附:checkpoint 由ckpt进程触发oracle进行checkpoint动作,将data buffer中的脏块(已经写在redo里记录但是没有写到datafile里的)的内容写入到data file里并释放站用的空间,由dbw后台进程完成,并修改controlfile和datafile的scn.
一般手工执行(alter system checkpoint)是由于要删除某个日志但是该日志里还有没有同步到data file里的内容,就需要手工check point来同步数据,然后就可以drop logfile group n.

 DBWn负责将脏块写入磁盘的后台进程。
DBWn会把块写出到所有磁盘，即分散在各个磁盘上，也就是说，DBWn会做大量的分散写（scattered write）；
LGWR则是向重做日志完成大量的顺序写（sequential write）。
从理论上讲，如果提交期间Oracle已经将已修改的块物理地写出到磁盘，就可以跳过写在线重做日志文件。但实际上，提交期间，只是由LGWR会把每个事务的重做信息写至在线重做日志，DBWn则在后台将数据库块刷新输出到磁盘。
这么做的原因就是分散写比顺序写慢多了。DBWn 在后台完成它的任务（很慢），而LGWR在用户提交后等待时完成自己的任务（这个任务比较快），就能得到更好的整体性能。尽管从技术上讲这样会使Oracle执行更多不必要的I/O（写日志以及写数据文件）。

附上参考链接

http://www.cnblogs.com/sumsen/archive/2013/01/13/2858417.html