ITPub博客

首页 > 数据库 > Oracle > 通过实验理解oracle增量检查点

通过实验理解oracle增量检查点

原创 Oracle 作者:wangyiou1988 时间:2012-03-05 15:29:37 0 删除 编辑

理解增量检查点:

检查点:分为完全检查点和增量检查点。

完全:所有的脏块都保存下来 =>手工存盘触发。

                           =>一致性停止数据库触发(normal,immediate,transactional)

完全检查点是如何工作的?=>把所有的脏块保存下来之后,在文件的文件头打上时间戳。  

不属于以上两种情况的都属于增量检查点。切换日志属于增量检查点。



我们从实验中深入解析一下:
现在我们设置一下,记录checkpoint信息

SQL>alter system set log_checklpoints_to_alert=true scope=spfile;

首先,我们切换一次日志。

SQL>alter system switch logfile;

我们开始查看一下日志的信息:

SQL>select * from v$log;

显示当前记录的日志是第二组。我们查看一下最近一次checkpoint的scn号:

SQL>select checkpoint_change# from v$database;

我们来查看一下日志里面的描述:

下面我们进行第2次切换日志:

SQL>select * from v$log;

SQL>select checkpoint_change# from v$database;

查看日志里的相关信息:

下面我们进行第3次切换日志,这次时间久长了很多。继续查看这三个信息:

SQL>select * from v$log;



 SQL>select checkpoint_change# from v$database;

查看日志里的相关信息:

我们进行第4次切换,查看这三个信息:

SQL>select * from v$log;

SQL>select checkpoint_change# from v$database;

查看日志

好,现在实验做到这,我们就开始分析一下:



    当我们第一次切换的时候:发现日志从2切换到3.,上一次checkpointscn号也属于第二组里,说明切换的过程没有发生检查点。但在日志里却记录了一个scn号码:563108.这也正是第三组记录数据库发生第一次变化时的scn号。

    当我们第二次却换的时候:3切到1.发现上一次checkpointscn号依然没有变。还是561661.日志里再次记录了一个scn号:563162,这个号就是第一组记录数据库第一次改变的scn号。

    这时我们进行第三次切换:这次就不一样了。注意我们v$log这里有个status,里面有几种状态:Inactive,active,current,意思分别是:没有脏数据,有脏数据没有checkpoint,当前组。从1组切换到2组,2的状态时active,说明里面有脏数据没有写到硬盘里,这可咋整,果然,这次触发了检查点。检查点从561661变成了563108,哎,这个数怎么这么眼熟呢,啊,想起来了,563108就是第三组第一次改变的号啊。但日志里记得怎么这么乱啊:

 

这是什么意思?

其实就是因为redo文件组太少啦,导致lgwr进程在切换redo files时,等待旧数据写入数据文件,也就是等待dbwn进程干活。就报:Checkpoint not complete.这其实是一个问题:它会导致主机cpu占用率居高不下,IO写入也居高不下,连接数据缓慢,甚至宕机。我们可以通过增加日志组来解决,但因为这是在实验,应用数据很少,所以下面马上就完成了操作,因为数据文件写完啦,很快。


这时,就说了,完成归档了 scn563108了。切换日志之后,现在的scn号是563221,也是当前日志的开始。

再次切换:从2-3,根据推理,在3里也有脏数据,会再次触发检查点。果然:上一次checkpointscn号发生了改变:从563108变成了563162,这个数字也出现过,是3切换到1的时候,日志记录的数字


日志也和上一次切换时表示的如出一辙。

也是不能checkpoint

通过这几次切换,我们对增量检查点有了些了解。增量检查点和检查点的区别就是:增量检查点不是实时进行的。


我们从2切到3,记录一下当时的scn:563108  没触发检查点

我们从3切到1,记录一下当时的scn:563162  没触发检查点

我们从1切到2,记录一下当时的scn:563221  因为2里有脏数据,触发了检查点,但checkpointscn不是563221,而是563108.它只写2里的脏数据,不写3,更不会写1.

我们从2切到3 ,记录一下当时的scn::563328  因为3里有脏数据,又触发了检查点,但checkpointscn不是563328,而是563162,它只写3里的脏数据,不写1,更不会写2.

 

在我们频繁的切换日志时,会有此类的实验结果,因为很繁忙,所以很多时候status 都是active.我们等10分钟之后,再次查看就发生了很大的变化。

SQL>select * from v$log;



SQL>select checkpoint_change# from v$database;

查看日志:

 

过了一段时间之后,数据库就自动把第一组和第二组的脏数据都写入了磁盘,进行着不断的增量检查点,两次,第一次写到563221,第二次写到563328.

哈哈,实验进行到这,大家对增量检查点有一定了解了吧






18.jpg

19.jpg

20.jpg

1.jpg

2.jpg

3.jpg

4.jpg

5.jpg

6.jpg

7.jpg

8.jpg

9.jpg

10.jpg

11.jpg

12.jpg

13.jpg

14.jpg

15.jpg

16.jpg

17.jpg

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25116248/viewspace-717742/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-12-21

  • 博文量
    91
  • 访问量
    1175611