ITPub博客

首页 > Linux操作系统 > Linux操作系统 > log buffer及日志管理深入分析及性能调整(三)

log buffer及日志管理深入分析及性能调整(三)

原创 Linux操作系统 作者:听海★蓝心梦 时间:2009-03-17 02:19:09 0 删除 编辑
2.    <!--[endif]-->log buffer的内部管理机制

日志缓冲区的内部管理分为两部分,一部分是重做记录的生成,另一部分就是重做记录写入联机日志

文件。这两部分不是孤立的,没有关联的。在生成重做记录的过程中,可能会触发LGWR将重做记录写入联机日志文件。

      我们先用一个实例来说明在日志缓冲区中的操作过程,并使用[file# , blk#]来表示某个数据块,file#表示文件号,blk#表示数据块号。

假设session 1发出更新语句:update redo_test set name='cdf' where id=1;

   Oracle首先找出id=1所在的数据块(假设为[file#4,blk#120])放入buffer cache,然后找出一个可用的回滚段数据块(假设为[file#2,blk#19]),将旧值'abc'放入该块,同时生成重做记录。然后将'cdf'放入表的数据块,再生成重做记录。这时的日志缓冲区的结构类似如下。(我们从前面描述日志缓冲区的内存结构时,知道重做记录中最重要的就下面列的这几列内容。同时,下面的一行就表示一个改动向量):

行号   事务id     file#  block# row    column     value

1      T1         2      19     -      -          abc

2      T1         4      120    1      2          cdf

   这时假设session 2发出其他更新语句:update t set c1=10 where c1=9;

   同样的道理,oracle找到该数据块(假设为[file#5,blk#200])放入buffer cache,并找到回滚段数据块(假设为[file#2,blk#30])存放旧值,生成重做记录,更新表的数据块,再次生成重做记录。这时的日志缓冲区的结构类似如下:

行号   事务id     file#  block# row    column     value

1      T1         2      19     -      -          abc

2      T1         4      120    1      2          cdf

3      T20        2      30     -      -          9

4      T20        5      200    20     1          10

             这时,session 1又发出更新语句:update redo_test set name='xyz1' where id=2,并提交(commit)。

       同样的方式处理回滚段和数据块,并生成重做记录。假设这时生成日志缓冲区假设为:

行号   事务id     file#  block# row    column     value

1      T1         2      19     -      -          abc

2      T1         4      120    1      2          cdf

3      T20        2      30     -      -          9

4      T20        5      200    20     1          10

5      T1         2      19     -      -          abc

6      T1         4      120    2      2          xyz1

7      T1         commit SCN    timestamp

   这时,我们可以注意到,提交标记也被记录到了重做记录中。从我们前面转储出的结果中也可以看到“sta: 9”的内容,这就是提交标记。每次提交时,都会生成一个SCN号,SCN号越小,说明发生的越早,其所属的重做记录就越排在前面。一旦用户发出commit语句,系统就会触发LGWR进程。这时,LGWR进程会将上面所显示的所有重做记录都写入联机日志文件中。注意,其中也包括尚未提交的事务T20

   LGWR写这些重做记录的过程中,又有其他session发出更新语句,并提交。这时的日志缓冲区假设如下所示:

行号   事务id     file#  block# row    column     value

1      T1         2      19     -      -          abc

2      T1         4      120    1      2          cdf

3      T20        2      30     -      -          9

4      T20        5      200    20     1          10

5      T1         2      19     -      -          abc

6      T1         4      120    2      2          xyz1

7      T1         commit SCN    timestamp                以上的重做日志正在由LGWR写入

------------------------------------------------------------------------------------------

8      T20        2      39     -      -          289  LGWR写时生成以下的重做日志

9      T20        5      498    220    3          190

10     T9         2      90     -      -          hhh

11     T9         9      100    20     9          xxx

12     T9         commit SCN     timestamp

13     T18        2      189    -      -          18

14     T18        10     29     300    10         20

15     T18        commit SCN     timestamp

LGWR写完第一批重做记录1到第7以后,就会立即开始写第二批重做记录(第8行到第15行)。注意,第二批重做记录中,存在两个commit,但LGWR不会分成两次来写,而是一次就将它们全部写入。当LGWR在写完第1到第7行的改动向量以后,这部分的日志缓冲区内存就被释放了,可以被新生成的重做记录所覆盖。

如果当前联机日志文件写完时,这时就需要转换到另外一个可写的联机日志文件上去,这个过程叫做日志切换。日志切换的大致过程包括:

<!--[if !supportLists]-->1)     <!--[endif]-->从控制文件中得到下一个可用的联机日志文件。

<!--[if !supportLists]-->2)     <!--[endif]-->记录写入当前联机日志文件的最后一个日志块的SCN(叫做high SCN)。关闭当前联机日志文件。

<!--[if !supportLists]-->3)     <!--[endif]-->增加SCN再次操作控制文件将下一个联机日志文件标志为CURRENT判断前一个联机日志文件里包含的重做记录所对应的脏数据块是否都已经写入数据文件,如果没有则标记ACTIVE;如果是则标记为INACTIVE如果数据库是归档模式那么LGWR将前一个联机日志文件加入归档列表中等待归档。

<!--[if !supportLists]-->4)     <!--[endif]-->打开新的联机日志文件组中的所有成员,记录当前日志序列号(log sequence)和第一个日志块的SCN(叫做low SCN),新一轮的重做记录开始。

我们经常看到当前日志文件的状态为CURRENT,而前一个日志文件的状态为ACTIVE的情况。实际上,这是由于内存中存在很多脏数据块,而脏数据块的写入是通过DBWR进程完成的。如果脏数据块没有积累到一定的量,DBWR是不会将它们写入数据文件的。所以,ACTIVE状态的日志文件表示该日志文件里包含的重做记录所对应的脏数据块还没有被DBWR进程写入数据文件。事实上,日志切换时触发增量检查点(incremental checkpoint),CKPT将会触发DBWR写脏数据块。增量检查点只是在控制文件中记录这时在检查点队列上的脏数据块在第一次修改时所对应的日志块在日志文件中的地址,这个地址叫做检查点位置(checkpoint position)。但是DBWR启动并不表示立即写脏数据块,除非脏数据块的数量达到一定程度,或超过一定时间等。我们来模拟一下这种情况。

SQL> select group#,status from v$log;

   GROUP# STATUS

---------- ----------------

        1 CURRENT

        2 INACTIVE

        3 INACTIVE

SQL> create table t2 as select * from dba_objects;

SQL> select group#,status from v$log;

   GROUP# STATUS

---------- ----------------

        1 ACTIVE

        2 CURRENT

        3 INACTIVE

我们可以看到,当创建了表t2的时候,发生了日志切换。如果没有看到日志切换,可以再删除表t2然后再创建表t2,如此反复几次,就能够引起日志切换。这时我们看到2号日志文件为当前打开的日志文件,其状态为CURRENT。而1号日志文件为上次打开的日志文件,状态为ACTIVE,就说明其对应的脏数据块还没有写入数据文件。这时我们可以等待一段时间,等待增量检查点的完成,也可以手工触发完全检查点(complete checkpoint),触发完全检查点时,DBWR将把所有脏数据块写入磁盘上的数据文件里。

SQL> alter system checkpoint;

SQL> select group#,status from v$log;

   GROUP# STATUS

---------- ----------------

        1 INACTIVE

        2 CURRENT

        3 INACTIVE

可以看到,1号日志文件的状态从ACTIVE变成了INACTIVE,说明其对应的脏数据块都已经写入了联机日志文件中。

这里要说明一点。增量检查点触发的DBWR写和完全检查点触发的DBWR写的优先级是不一样的,这也就是为何在上面的例子中进行日志切换以后,前一个日志的状态为ACTIVE,而且要等一段时间以后其状态才能变为INACTIVE,而我们发出alte system checkpoint以后立即变为INACTIVE的原因。因为日志切换触发增量检查点,而增量检查点通知DBWR启动,但是由于这时触发DBWR启动的条件的优先级较低,所以DBWR不会立即去写脏数据块,而是要等一段时间才会实际的写脏数据块。所以我们等待日志状态变为INACTIVE的时间就是等DBWR开始真正写的时间加上DBWR实际写入数据文件所花费的时间。而alte system checkpoint触发完全检查点,其优先级很高,所以通过它触发的DBWR会立即去写脏数据块,所以我们等待日志状态变为INACTIVE的时间就是DBWR实际写入数据文件所花费的时间。

我们可以设定初始化参数:log_checkpoints_to_alerttrue,从而将检查点启动和结束的时间记录到跟踪文件里去。这里是所记录的信息的一个例子:

Wed Dec 13 18:27:48 2006

Beginning log switch checkpoint up to RBA [0x85.2.10], SCN: 2164686

Thread 1 advanced to log sequence 133

 Current log# 3 seq# 133 mem# 0: /oracle/oradata/ora10g/redo03.log

Wed Dec 13 18:32:45 2006

Completed checkpoint up to RBA [0x85.2.10], SCN: 2164686

……

Wed Dec 13 19:02:15 2006

Beginning global checkpoint up to RBA [0x85.883.10], SCN: 2165818

Completed checkpoint up to RBA [0x85.883.10], SCN: 2165818

从上面可以看到,由于日志切换而发生的增量检查点从18:27:48开始,到18:32:45结束,用了5分钟的时间。而我们强制进行完全检查点,则只用了大概1秒钟不到的时间。实际上,DBWR在实际写入数据文件所花费的时间都是一样的,也就是不到1秒。5分钟的差别就在于DBWR等了5分钟才实际开始写数据文件。

在大致了解了日志缓冲区的操作过程以后,我们来深入了解一下其内部的工作原理是怎样的。

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

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

注册时间:2009-02-18

  • 博文量
    256
  • 访问量
    1195241