Oracle之checkpoint

什么是checkpoint？

checkpoint能干什么？

checkpoint是怎么运行的？

这是我们在了解检查点概念的时候，需要理解的问题。也是我们在理解检查点的时候，经常不能整明白的三个问题。 我们先不忙着对这三个文件进行理解。一个事物的出现，必然有他出现的理由，checkpoint也固然如此。 大家都知道在我们的系统里，存储是数据的最后的归属之地，数据库更是如此，只有数据落地生根的进入了物理的存储空间里，这个数据才算是放心的能够保存了，所以如果要数据保证安全不丢失，及时的把他们放到了安心的地方就可以了，但是反观而谈，进入存储空间势必带来IO，而这个IO往往带来相对的性能上的劣势。所以要即保证数据的安全，有同时保证性能的优化，这个及时就要做到恰到好处了。万事的两面性就带来了研究的快乐。这个检查点也是来之于此的。对于 Oracle来说主要的文件，大家都知道。无非就是控制文件，数据文件和重做日志文件，此为Oracle数据库实例能够运行的三个为高权重的文件类型了。 控制文件其是数据库实例的信息中心，数据文件更不必谈，是根本，重做日志文件，其实也是用来保证数据库的crash时的数据安全保证的。对于此三种文件其中最为常见的IO，log buffer写入到log file，buffer cache里的脏数据之写于数据文件。其中前者是顺序写入的。从前向后不断写入，直至写满进行下一组的切换，后者与前者不同，并不是连续写入的，是离散型的，不同的数据需要写入到不同的块里，不同的块需要进行不同的寻址，切换磁道等操作，这里读也亦然，不过读非本文说关心所在，暂不谈之，log buffer的写入LGWR为之。当数据Commit或者Rollback之刻。LGWR将写log buffer于Log file，我们故称redo log的写入是同步之写入。即数据生效及回滚是，redo条目必是在物理存储上记下来的，由此crash后，实例能够得以恢复。观data， data存储在data file中。用时，加载到buffer cache里，进行修改并进行访问，但是buffer cache中的数据不一定和data file中的一致，为何，因为上面提到了，为保证实例行之高效，修改了的数据(dirty data脏数据)并不会马上写入到数据文件。所以DBWR的写入和commit以及rollback并非同步而为。如此这般，如若实例crash比如断电或者shutdown abort，buffer cache里的dirty data并不能在data file里记录下来，这样岂不是数据将会丢失么，确实，现在data file里的数据并不和我们crash的时候一致。但是我们开启了数据库以后发现，已经提交的数据依然可以表现出来，不过是那些还没有来的及提交的数据没有叻。确实，虽然数据库库里的data file里的data不一致了，不过在startup的过程中，Oracle已经悄然为你上次的abort买单了。上面提到了redo log，这个redo log就是Oracle买单得以实现的手段了。Oracle记录了重做的记录条，根据重做的记录条，把那些还没有体现到data file里的数据重新做过一遍，也就达到目的了。不过，Oracle怎么知道你要做那些重做的内容，他会把所有的重做都做过么，这样来保证他找出来的重做条目就是我们所需的呢，这写就是通过上面提到的checkpoint来实现的。

这里累文叠字般的并没有对我们的checkpoint介绍过多，看似介绍的更多是数据库如果保证我们的数据在高效运行过程中的安全，实为提示大家我们提到的checkpoint并不是保证实例的运行状态的，最后一句话，点明了，checkpoint目的是恢复数据库而来的。是在恢复数据库的时候确定恢复的条目而来的。而别无他用。checkpoint是学习Oracle里的一个大家常觉得困难和不易理解的知识领域，如果你能够先认知下checkpoint不过是Oracle实例在crash recovery里的一个恢复过程中需要用到的手段，那么checkpoint的学习你就已经先有所得了。

一钱窥豹，焉识其貌。本文仅告知checkpoint的由来，哪么checkpoint如何来实现其目的，其又是如何在Oracle里表现，我们在认知checkpoint中又会有哪些误区。在后面的文章中我们再逐一道来。

上回说到了checkpoint的由来，checkpoint的出生意义不在于数据库本身的运行，其真正的价值体现在数据库的crash/instance recovery上。而且不是解决恢复的问题。恢复是比较容易搞定的，解决的是高效恰达好处的问题。做事不难，做到恰到好处就是个学问了，checkpoint就是这个学问。 题目中提到的scn就是我们这个文章的主角了。题目立的是“checkpoint中的scn”， 这里scn绝不应该硬扯为checkpoint里的东西。那么scn是什么东西了。以至于我不得不冒天下之大不韪而将其扯过来叻。

SCN，名为 system change number。 又一个容易骗到人的名字。至少我最开始是经常被这个change骗到的。不过顺着自己对oracle的知识足够多的了解，也慢慢体会出Oracle在这个名字上所费尽的心思了，对于了解Oracle不是很系统，不能以面来贯彻体系的朋友，暂时不要去理解这个名词，你就先就把SCN当做一个代号，这个代号标识出Oracle运行的某个时刻。其实在10g里已经完全让我们这样来理解这个scn了。通过scn_to_timestamp我们可以把根据指定的scn号找到对应的数据库时间。 timestamp_to_scn我们又可以根据数据的指定的时间找到此时对应的scn号。我们来看看

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
755287

这里是获取当前的scn号。别看他封在了dbms_flashback里，他绝对不是只和这个有关的。 上面说过来，scn就是标识某个运行点的，其实就是运行的时间， 按照这样。

当我们再执行以下上面的方法，结果是不是不一样呀，

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
755541

答案是肯定的，肯定是不一样的。

即使现在没有任何数据写入数据库。我没有做任何修改的操作，你再执行，又会改变。

为了帮助你自己，先把system change number从你的脑海里抹掉，知道SCN是这几个词的缩写就可以了，不要再去揣测他了。你现在功力尚浅，小心走了火入了魔。

不过还好， 至少你可以看到了，和时间是有关的。(这段并不是有意误导大家，从过来人的体验，现在这样理解容易，以后有能力了，自然就对这个system change number有了更深入的理解而豁然开朗了)。

scn和时间之间的转换

SQL> select scn_to_timestamp(755541) from dual;

SCN_TO_TIMESTAMP(755541)
--------------------------------------------------------------------------------
03-6月 -10 02.04.31.000000000 下午

时间到scn的转换

SQL> select timestamp_to_scn(to_timestamp('2010-06-03 14:04:31', 'yyyy-mm-dd hh24:mi:ss:ff')) from dual;

TIMESTAMP_TO_SCN(TO_TIMESTAMP(
------------------------------
755541

那么这个可以干嘛呀。

标识呀，这个最大的功能就是标识了。一旦某些的scn一样，那么我们就知道他们是同一次操作的了。如果不一样，就是不同次的操作了。这样这个scn号就好理解了。

既然是scn的作用是标识，那么他都标识在什么重要的东东上呀。

from:http://blog.csdn.net/inthirties/archive/2010/06/03/5644703.aspx