ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 揭密Oracle之七种武器之四:揭密Buffer Cache中的链表

揭密Oracle之七种武器之四:揭密Buffer Cache中的链表

Linux操作系统 作者:kingsql 时间:2013-11-04 13:15:03 0 删除 编辑
[i=s] 本帖最后由 vage 于 2012-7-4 11:21 编辑

揭密Oracle之七种武器之四:揭密Buffer Cache中的链表

    有日了没写东西了。又是看房又是讲课,好多朋友问我是不是不写了,怎么会呢,分享知识,也是自我总结的一个过程,对自己的提高也是有帮助
的吗。
    前段时间,一直有人问我Buffer Cache的链表,LRU、辅助LRU、检查点队列等等。检查点队列已经有很多文章讨论过了,我就不再重复的制造轮子

另外,还有主LRU冷热端的相关内容,这一块我也不再详细描述,因为也有相关的文章。
我主要说一下主LRU、辅助LRU和LRUW相关的内容。
本篇文章没有使用DTrace和GDB,难度较低,但实验内容较多。我先将结果写在前面,如果没时间按个看实验,大概了解一下也行。
1、辅助LRU的定位,是让进程可以在辅助LRU中尽快找到可用块,因此,辅助LRU中存放的,都是相较主LRU,更加没有用的块。比如全表扫描的
块,都会被放在辅助LRU。另外,当空间紧张时,前台进程会将脏块移到LRUW,这些从LRUW写出的脏块,写完成后也会放入辅助LRU。这样辅助LRU中块更
多,前台进程更加容易在辅助LRU中找到可用块。
2、非全表扫描,先到辅助LRU中寻找可有块,找到后会将其从辅助LRU中,移到主LRU冷端头。
3、如果非全表扫描较多,辅助LRU中块会越来越少,为了保持比例(辅助LRU占整个LRU总块数的20%到25%左右),SMON进程会3秒一次持有LRU
Latch,将主LRU冷端末的块移到辅助LRU。
4、全表扫描也先到辅助LRU中寻找可用块,但全表扫描的块仍将留在辅助LRU,不会调往主LRU冷端头。因此全表扫描的块将很快被覆盖。全表
扫描操作将只使用辅助LRU(也会用到主LRU,只会用到很少量的主LRU),一次大的全扫操作,可以将辅助LRU的所有块覆盖一遍或多遍。
5、数据库刚启动时,或刚Flush Buffer_cache时,所有块会被放在辅助LRU中。
6、前台进程(服务器进程)扫描主、辅LRU时,会将遇到的TCH为2以下的脏块,移到主LRUW。
7、DBWR三秒一次,扫描检查点队列的长度、确定是否要写脏块。另外,DBWR每三秒还会扫描主LRUW,将其中的脏块移到辅助LRUW,然后写到磁
盘。
8、从检查点队列写到磁盘中的块,不会改变它在LRU链表中的位置。从LRUW写到磁盘中的块,会被放于LRUW,以供马上覆盖。

基本上就这些了。下面开始吧。本篇比较简单,没有DTrace,更进一步的DTrace测试,放在下篇中吧。只是实验较多,繁琐了些。


第 一 章       一个测试理解什么是主、辅LRU


    LRU是Buffer Cache池中的重要链表,它的作用我不再详述,已经有很多相关资料。这次主要和大家讨论下主LRU、辅助LRU的作用。
    先来看一个测试。
步1:环境介绍
    先来看看Buffer Cache的大小:
SQL> show sga
Total System Global Area 1073741824 bytes
Fixed Size                  1284344 bytes
Variable Size             960497416 bytes
Database Buffers          104857600 bytes
Redo Buffers                7102464 bytes
Buffer Cache大小100M。
    再来看看测试表大小:
SQL> set linesize 1000
SQL> col segment_name for a30
SQL> SQL> select segment_name,bytes/1024/1024 from dba_segments where segment_name='A3_70M';

SEGMENT_NAME                   BYTES/1024/1024
------------------------------ ---------------
A3_70M                                      80
SQL> SQL> select segment_name,bytes/1024/1024 from dba_segments where segment_name='A4_70M';

SEGMENT_NAME                   BYTES/1024/1024
------------------------------ ---------------
A4_70M                                      80
两张测试表,A3_70M、A4_70M,各自大小80M。本来是想把它们两个大小建为70M的,所以名字带有后缀_70M,但建的大了一点,不过,这无所
谓,不会影响我们的测试结果。
步2:刷新Buffer Cache池,观察LRU链长度
SQL> alter system flush buffer_cache;
SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
      6238       6238       6219          0          0
      6237       6237       6224          0          0
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
         0          0          0          0          0
16 rows selected.
这个视图返回16行,但只有两行有数据。其他行都是0,原因是什么?
查一下select name from v$latch_children where name ='cache buffers lru chain'; 就可以知道,我一共有16个cache buffers lru
chain Latch,但只有两个被使用了。
每一个cache buffers lru chain latch,都算作一个“工作组”,work set。意义是指每个cache buffers lru chain latch,都对应一组主
、辅LRU链,和脏LRU链。
x$kcbwds视图中CNUM_SET列,统计工作组所有块数量。简单点说,也就是LRU链上所有块的数量。
CNUM_REPL列是主、辅LRU链表中所有的块数。
ANUM_REPL列是辅LRU链上所有的块数。
用CNUM_REPL-ANUM_REPL,即为所有主LRU链上的块数。
CNUM_WRITE、ANUM_WRITE这个列对应LRUW(也即为脏LRU)链,CNUM_WRITE为LRUW链中所有块数,ANUM_WRITE为辅助LRUW中的块数。两个相减,
要以得到主LRUW中的块数。
这个测试中,先不用观察LRUW。我们先只关注主、辅LRU。
来看我们的显示结果吧,两个工作组加起来,一共12475个块。
另外,可以看到,CNUM_REPL的ANUM_REPL列的几乎相等,这说明绝大多数块,都在辅助LRU链表中,这是为什么呢?这是我们今天第一点结论,
flush了buffer cache、或刚刚开启数据库时,所有的可用Buffer都会链接到辅助LRU中。

步3:先查询a3_70M,再查询a4_70M,分别观察物理读。(注意顺序,先查询A3_70M,再查询A4_70M)
SQL> set autot trace
SQL> select count(*) from a3_70m;

Execution Plan
----------------------------------------------------------
Plan hash value: 850873958
---------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     1 |  1643   (1)| 00:00:20 |
|   1 |  SORT AGGREGATE    |        |     1 |            |          |
|   2 |   TABLE ACCESS FULL| A3_70M |  1511K|  1643   (1)| 00:00:20 |
---------------------------------------------------------------------

Statistics
----------------------------------------------------------
        207  recursive calls
          0  db block gets
       9292  consistent gets
       9271  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select count(*) from a4_70m;

Execution Plan
----------------------------------------------------------
Plan hash value: 2047399966
---------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     1 |  1643   (1)| 00:00:20 |
|   1 |  SORT AGGREGATE    |        |     1 |            |          |
|   2 |   TABLE ACCESS FULL| A4_70M |  1502K|  1643   (1)| 00:00:20 |
---------------------------------------------------------------------

Statistics
----------------------------------------------------------
        207  recursive calls
          0  db block gets
       9292  consistent gets
       9259  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
          1  rows processed

可以看到,第一次查询A3_70M和A4_70M,物理读分别是9200多。

步4:再次查询a3_70M,再查询a4_70M,分别观察物理读。(顺序无所谓,先查谁都可以)
SQL> select count(*) from a3_70m;

Execution Plan
----------------------------------------------------------
Plan hash value: 850873958
---------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     1 |  1643   (1)| 00:00:20 |
|   1 |  SORT AGGREGATE    |        |     1 |            |          |
|   2 |   TABLE ACCESS FULL| A3_70M |  1511K|  1643   (1)| 00:00:20 |
---------------------------------------------------------------------

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9269  consistent gets
        213  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select count(*) from a4_70m;

Execution Plan
----------------------------------------------------------
Plan hash value: 2047399966
---------------------------------------------------------------------
| Id  | Operation          | Name   | Rows  | Cost (%CPU)| Time     |
---------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     1 |  1643   (1)| 00:00:20 |
|   1 |  SORT AGGREGATE    |        |     1 |            |          |
|   2 |   TABLE ACCESS FULL| A4_70M |  1502K|  1643   (1)| 00:00:20 |
---------------------------------------------------------------------

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9269  consistent gets
       9135  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
发现没有,A3_70M的物理读在第二次查询时大量下降,只有213次。而A4_70M在第二次查询时,物理读下降很不明显,还是9200次左右。
可以再测个几遍,情况依旧。A3_70M的物理读很少,而A4_70M的物理读很多。
这是我们今天的问题一:考虑这是为什么。
下面继续我们的问题2。

步5:连续两次查询A3_70M和A4_70M
SQL> select count(*) from a4_70m;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9269  consistent gets
       8686  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select count(*) from a4_70m;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9269  consistent gets
       8722  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
这是两次A4_70M的结果对比,多次查询A4_70M之后,物理读下降到了8700多,然后不再下降。
再来看两次连续查询A3_70M的结果对比:
SQL> select count(*) from a3_70m;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9269  consistent gets
        600  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
SQL> select count(*) from a3_70m;
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       9269  consistent gets
          0  physical reads
          0  redo size
        414  bytes sent via SQL*Net to client
        381  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
第一次有600次物理读,第二次就没有了。
问题2出来了,考虑这是没什么。

步6:暂时总结
1、A3_70M和A4_70M表大小一样。行数一样、所占空间也一样,都是80M
2、第一次查询时,我们是先查询A3_70M,再查A4_70M。如果你反过来,先查A4_70M,将看到A4_70M的物理读在第二次查询时大大减少,连续两
次查询时物理读为0。
两个问题:
1、为什么第一次查询时,先查的表,在第二次查询时物理读会大大减少,而后查的表则不会。
2、为什么第一次查询时,先查的表连续两次查询时物理读会减少为0,而后查的表不会。
一个提示:可以观察一下我们开始提到的x$kcbwds视图。

步7:如何观察块处在哪个链上。
如何进一步分析这个问题?其实这两个问题的回答,都需要着落到一件事上,就是要分析两个表对应的块,分别在什么链上。是在主LRU,还是
辅LRU。如何进行这个观察呢?其实很简单,x$bh中有个LRU_FLAG列,通过这个列,就可以确定块在哪个链表上。
我们来看一下这个视图:
SQL> select lru_flag,count(*) from x$bh group by lru_flag;

  LRU_FLAG   COUNT(*)
---------- ----------
         6       3081
         2       6734
         8          2
         0       2658
在我的测试库中,我观察到的LRU_FLAG有4种值,6、2、8和0。这4个值分别代别什么意义呢?确定这个其实很简单,DUMP一下块对应的Buffer
就行了,以LRU_FLAG为6的为例:
(1)、随便查找LRU_FLAG为6的一行:
SQL> select lru_flag,file#,dbablk,TS# from x$bh where LRU_FLAG=6 and rownum=1;
  LRU_FLAG      FILE#     DBABLK        TS#
---------- ---------- ---------- ----------
         6          5      12459          4
(2)、如下DUMP一下这个BUffer:
SQL> alter session set events 'immediate trace name SET_TSN_P1 level 5';
Session altered.
SQL> alter session set events 'immediate trace name BUFFER level 0x014030ab';
Session altered.
上面这两个命令,“SET_TSN_P1 level 5”中的5,是表空间号加1得到的。也就是TS#+1。
第二个命令中“BUFFER level 0x014030ab”,其中0x014030ab,是5号文件12459号块的DBA。
这个DBA是如何计算出的?其实我是在另一个会话中DUMP一下5号文件12459号块,查看DUMP结果才得到的,Oracle也提供了一个包,其实有个函
数可以根据文件号、块号生成DBA,包名、函数名我都忘了,只好用笨方法。
好,来查看DUMP结果吧,到user_dump_dest目录中,找到日期最靠后的(我一般是ls -lFrt),它就是我们刚刚生成的DUMP文件。在它的开头,
我们可以看到如下内容:
*** 2012-07-03 08:58:36.571
*** SERVICE NAMESYS$USERS) 2012-07-03 08:58:36.523
*** SESSION ID874.3) 2012-07-03 08:58:36.523
Dump of buffer cache at level 10 for tsn=4, rdba=20983979
BH (7bbf0764) file#: 5 rdba: 0x014030ab (5/12459) class: 1 ba: 7b9dc000
  set: 5 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
  dbwrid: 0 obj: 9738 objn: 9738 tsn: 4 afn: 5
  hash: [7d7e687c,8e94b67c] lru: [7bbe80b8,7bbf0704]
  lru-flags: moved_to_tail on_auxiliary_list
  ckptq: [NULL] fileq: [NULL] objq: [7bbf075c,7bbe8110]
  st: XCURRENT md: NULL tch: 0
  flags: only_sequential_access
  LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
  buffer tsn: 4 rdba: 0x014030ab (5/12459)
  scn: 0x0000.00418edb seq: 0x01 flg: 0x06 tail: 0x8edb0601
  frmt: 0x02 chkval: 0xc400 type: 0x06=trans data
我对这里面的东西,不过多解释了,其实有一行:
  lru-flags: moved_to_tail on_auxiliary_list
这一行说明了块对应Buffer所在LRU链表的状态。Buffer目前在辅助LUR,moved_to_tail说明Buffer正移向链表末尾。
好了,我们已经总结出来,LRU_FLAG列为6,说明Buffer在辅助LRU链表。
其他的我不再一一列出测试过程了,总结一下,LRU_FLAG为6、4,说明BUffer在辅助LRU中。为0、2,说明在主LRU的冷端,为8、9的,说明在
主LRU的热端。
步8:问题1:为什么第一次查询时,先查的表,在第二次查询时物理读会大大减少,而后查的表则不会
让我们来观察一下A3_70M、A4_70M 的块都在什么链上
SQL> select lru_flag,count(*) from x$bh a,dba_objects b where a.obj=b.data_object_id and object_name='A3_70M' group by lru_flag;

  LRU_FLAG   COUNT(*)
---------- ----------
         2       8554
         0          1
SQL> select lru_flag,count(*) from x$bh a,dba_objects b where a.obj=b.data_object_id and object_name='A4_70M' group by lru_flag;

  LRU_FLAG   COUNT(*)
---------- ----------
         6       3082
         2        366
         0          1
这两条语句,我就不再过多解释了,根据LRU_FLAG列的值,我们可以确认,A3_70M,共有8555个块在Buffer Cache中,所有相关的块都在主LRU
链。A4_70M,只有3400多个块在Buffer Cache中,而且大部分块都在辅助LRU。
为什么A3_70M的块,被读进Buffer Cache时,大多被放置在主LRU的冷端?而A4_70M的块,则被放进辅助LRU呢?

能回答这个问题,我们今天的问题也就有了答案。
步9:回答问题1
有如下三点基础知识:
1、当数据库刚刚打开、或刚刚做过FLush Buffer_cache操作时,所有的块,都被放进辅助LRU。
2、进程寻找可用块时,先会在辅助LRU中查找,然后才会到主LRU中找。
3、Oracle会保持20%至25%左右的块在辅助LRU链,80%的在主LRU。这一点,从观察x$kcbwds中的CNUM_REPL、ANUM_REPL列,可以很容易的验证

有了这三点基础知识,让我们来得出结论吧:
当所有块都在辅助LRU时,Oracle为了急于保证主、辅LRU,块数量80%,20%的比例,第一次查询时,会将大量的块移到主LRU。也就是说,第一
次查询A3_70M时,大至步骤是这样的,分两种情况:
一、主LRU几乎为空时:
1、在辅助LRU找到可用块。
2、将它移到主LUR
3、将数据读入此块。
二、当主、辅LRU的块数量比例到达80%、20%后
1、在辅助LRU找到查用块
2、所处链表不变,直接将数据读入此块。
3、物理读完成后,块还在辅助LRU中。
由于第一次查询A3_70M时,主LRU几乎为空,所以,它的绝大部分的块被放在了主LRU,少部分块被放入了辅助LRU。
根据比例,辅助LRU中将会有3000到3200个左右的块。根据我们的测试结果,全表扫描A4_70M后,有3000多个块在辅助链上。根据这个,得出我
们今天第二个结论,正常的全表扫描操作,将只会反复使用辅助LRU中的块。
当然,我们的测试中,还是有少量A4_70M的块进入到了主LRU,不过数量不多,只有几百个。

好了,回答一开始的问题吧,第一次查询A3_70M,Oracle会了保持主、辅LRU的比例,将很多被A3_70M占用的块移进了主LRU,所以,A3_70M在
Buffer Cache中可以有很多块,再次查询A3_70M时,物理读大大减少。
而全表扫描A4_70M,只能反复使用辅LRU中的块,几乎无法占用主LRU中的块,因此在Buffer Cache中块数较少,每次物理读都很高。

步10:回答问题2
为什么连续两次查询A3_70M,就没有物理读了?可以连续两次全表扫描一下A3_70M,查看结果:
SQL> select lru_flag,count(*) from x$bh a,dba_objects b where a.obj=b.data_object_id and object_name='A3_70M' group by lru_flag;

  LRU_FLAG   COUNT(*)
---------- ----------
         6       1004
         2       8254
         0          1

一共9000多个块,8000多个在主LRU,1000多一点在辅助LRU。A3_70M表的全部块,都可以被缓存到Buffer Cache中。
当再次查询A4_70M时,A4_70M将又反复占用辅助LRU中的块,A3_70M留在辅助LRU中的1000多一点块会被覆盖,所以,当A3_70M、A4_70M交替查
询时,每次A3_70M在辅助LRU中的块都会被覆盖,因此,它会有少量物理读,但,当连续查询A3_70M时,辅助LRU中的块没被覆盖,就不会有物理读了。
好,问题已经解答了,让我们总结一下吧。
总结:
1、flush了buffer cache、或刚刚开启数据库时,所有的可用块都会链接到辅助LRU中。
2、查找可用块的过程,是先找辅助LRU,再从主LRU的冷端尾开始找。
3、全表扫描在辅助LRU找到块后,不会将块读进主LRU。所以,全表扫描的结果很容易被覆盖。
4、非全表扫描时,在辅助LRU找到块后,会将块移到主LRU的冷端头。这一点我们还没验证过。
5、全表扫描的块,如果再次以非全表扫描方式访问,TCH列会增加,但会一直留在辅助LRU,不会被移到主LRU冷端头。只有等到TCH值超过2时,才会在
下次被扫描到时,移到主LRU热端。
第4点和第5点,我们并没用测试验证,但找个这样的测试也是很简单的。留给大家自己验证一下吧,研究Internal,结果不是目的,过程更有
意义。

最后还有一个注意事项,这个测试只能在10G下做,因为11GR2后有些改变,即使是开库后第一次全表扫描,也不会把块移往主LRU,这样其实更合理,Oracle其实一直没有停止对内核优化步伐。
另外,本篇中除这个测试外,其他测试都可以在10G、11GR2下做。


    第 二 章       LRUW


脏块什么时候会进入LRUW ? 流行的说法有以下几种:
1、DBWR 每3秒醒来时,会将脏块收集到LRUW,当LRUW中脏块达到一定阀值时,将触发DBWR写LRUW中的脏块。
2、当前台进程(也就是服务器进程)扫描LRU时,会将发现的脏块移到LRUW中,当LRUW中脏块达到一定阀值时,将触发DBWR写LRUW中的脏块。
3、当前台进程扫描LRU的一定数量的块后,都没有发现可用块,此时会触发紧急写。前台进程等待,DBWR将脏块从检查点队列移到LRUW,从
LRUW写到磁盘。
以上这三种说法,第一种并不存在,或者说,都观察不到。
通过x$kcbwds视图的CNUM_WRITE、ANUM_WRITE列,就可以观察到主、辅LRUW链的长度。可以一直不停的多观察几十秒,没有发现这两个列不为0
。3秒的说法,不功自破。
但是,并不能说3秒写磁盘的操作不存在,只是,并不是以这种形式。
第二种说法,流传很广,也的确会有这种情况出现,但真实情况和流行说法还是会有不同。

具体怎么来验证一下呢。先来做个测试:
步1:环境配置:
写脏块有两种途径:通过检查点队列、通过LRUW。为了避免从检查点队列写影响我们的测试结果,我们要将增量检查点关闭。
其实,不是关闭,而是将增量检查点周期设的很大,在我们的测试期间,保证它不会触发。
需要设置如下几个参数:
SQL> show parameter log_checkpoint_timeout
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_timeout               integer     100000
SQL> show parameter mttr
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target               integer     0
将log_checkpoint_timeout设置为了10万秒。fast_start_mttr_target设置为0。
另外,10G之后,fast_start_mttr_target设置为0时,Oracle将打开一个Self Tune Checkpoint(自调节检查点)的功能,将它也关闭:
SQL> alter system set "_disable_selftune_checkpointing"=true;
System altered.
经过这样的设置,增量检查点虽然没有关闭,也和关闭差不多了,10万秒才会被触发。
当然,日志切换时还会触发一个“日志切换时的增量检查点”,虽和普通的增量检查点有不同,但大体上类似增量检查点。这个只要建个稍大
点的日志文件,就可以解决,比如,我的日志文件是500M。
步2:观察当前系统中的脏块
SQL> select count(*) from v$bh where dirty='Y';
  COUNT(*)
----------
        46
步2:在另一个会话中,扫描个非全表扫描
select /*+index(a2_70m)*/ * from a2_70m where id1<=100000000;
索引范围扫描,将先找辅助LRU、再找主LRU。
步3:在步2中的索引范围扫描执行期间,不停的显示:
select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
select * from v$sysstat where name in ('dirty buffers inspected');
第一条语句可以查看LRUW的长度信息,第二条语句,可以观察前台进程在扫描LRU时,跳过的脏块数。我们可以观察到如下结果:

…………………………………………省略一部分相同的结果……………………………………………………
SQL> select * from v$sysstat where name in ('dirty buffers inspected');
STATISTIC# NAME                                                                  CLASS      VALUE    STAT_ID
---------- ---------------------------------------------------------------- ---------- ---------- ----------
        94 dirty buffers inspected                                                   8        650 1344569897
SQL>
SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6238       1522          0          0
      6237       6237       1541          0          0
SQL> select * from v$sysstat where name in ('dirty buffers inspected');
STATISTIC# NAME                                                                  CLASS      VALUE    STAT_ID
---------- ---------------------------------------------------------------- ---------- ---------- ----------
        94 dirty buffers inspected                                                   8        650 1344569897
SQL>
SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6237       1523          1          0
      6237       6235       1541          2          0
SQL> select * from v$sysstat where name in ('dirty buffers inspected');
STATISTIC# NAME                                                                  CLASS      VALUE    STAT_ID
---------- ---------------------------------------------------------------- ---------- ---------- ----------
        94 dirty buffers inspected                                                   8        653 1344569897
SQL>
SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6237       1520          1          0
      6237       6235       1539          2          0
SQL> select * from v$sysstat where name in ('dirty buffers inspected');
STATISTIC# NAME                                                                  CLASS      VALUE    STAT_ID
---------- ---------------------------------------------------------------- ---------- ---------- ----------
        94 dirty buffers inspected                                                   8        653 1344569897

…………………………………………省略一部分相同的结果……………………………………………………
SQL>
SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6238       1507          0          0
      6237       6237       1527          0          0
SQL> select * from v$sysstat where name in ('dirty buffers inspected');
STATISTIC# NAME                                                                  CLASS      VALUE    STAT_ID
---------- ---------------------------------------------------------------- ---------- ---------- ----------
        94 dirty buffers inspected                                                   8        653 1344569897
…………………………………………省略一部分相同的结果……………………………………………………

前面的观察结果,dirty buffers inspected的值一开始为650,当变为653时,同时,可以在CNUM_WRITE列看到,此列的值增加了3。
这证明有三个脏块被跳过,移到了LRUW上。但是,不同于通常的说法,没有等LRUW中脏块数达到什么阀值,很快的,这三个脏块就被写的磁盘
了。
3个块脏块,绝对没有到达任何阀值。那么,是什么情况触发的写脏块呢?
3秒,是否是三秒呢?
其实测试很简单,set time on可以打开时间提示符,打开提示符后再试:
13:23:25 SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6238       1523          0          0
      6237       6237       1549          0          0
13:23:25 SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6231       1542          7          0
      6237       6237       1512          0          0
13:23:25 SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6206       1510         32          0
      6237       6237       1505          0          0
……………………………………省略部分相同内容……………………………………
13:23:26 SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6195       1509         43          0  <--------------此处主LRUW上有43个脏块
      6237       6237       1515          0          0
……………………………………省略部分相同内容……………………………………
13:23:27 SQL> 13:23:27 SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6195       1504         43         43  <--------------主LRUW上的43个,被移到了辅助LRUW上。
      6237       6227        939         10         10
……………………………………省略部分相同内容……………………………………
13:23:27 SQL> select CNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE ,ANUM_WRITE  from x$kcbwds where cnum_set>0;
  CNUM_SET  CNUM_REPL  ANUM_REPL CNUM_WRITE ANUM_WRITE
---------- ---------- ---------- ---------- ----------
      6238       6238       1538          0          0
      6237       6237        940          0          0
在13:23:25时,有脏块被移到LRUW,我没有将dirty buffers inspected的值显示出来,其实dirty buffers inspected正好也增加了7。之后
脏块数慢慢增加,到13:23:27,两条LRUW上的脏块已经合计53个。
而且,可能很容易观察到,13:23:27 时,有43个脏块,从主LRUW移到辅助LRUW,然后被写到磁盘。
从13:23:25 ,到13:23:27,正好3秒。
你可以做更多的测试,我的测试结果,每次LRUW上有脏块,总是不超过3秒,就会被写到磁盘。

如果你觉得这个测试太简单了,猜测的部分太多,没关系,耐心等下,后面会有DTrace版的验证方法。这里不再详述。

回到开头的流利说法:
1、DBWR 每3秒醒来时,会将脏块收集到LRUW,当LRUW中脏块达到一定阀值时,将触发DBWR写LRUW中的脏块。
2、当前台进程(也就是服务器进程)扫描LRU时,会将发现的脏块移到LRUW中,当LRUW中脏块达到一定阀值时,将触发DBWR写LRUW中的脏块。
其实这两种说法都有不准确的地方,准确说是这样的:
1、DBWR 每3秒醒来,之后它会做两件事:
  (1)、检查检查点队列长度,如果脏块太多、恢复时间有可能超过fast_start_mttr_target参数的值,开始沿着检查点队列写脏块。
  (2)、检查LRUW,有脏块就写。
2、当前台进程(也就是服务器进程)扫描LRU时,会将发现的脏块移到LRUW中,等待3秒一次DBWR醒来,将脏块写磁盘。
前面说的流行说法还有第三点:
3、当前台进程扫描LRU的一定数量的块后,都没有发现可用块,此时会触发紧急写。前台进程等待,DBWR将脏块从检查点队列移到LRUW,从
LRUW写到磁盘。
这种说法容易理解,这是紧急情况。前台进程已经在等待Free Buffer Waits了,DBWR不会再按检查点队列依次写,而是从LRU中碰到脏块就移
到LRUW、然后写到磁盘。从LRUW写和从检查点队列写区别是什么呢?为什么这种紧急情况写,就要从LRUW写呢?
下面继续。

第 三 章    写完的脏块如何处理


从LRUW写和从检查点队列写区别是什么呢?为什么这种紧急情况写,就要从LRUW写呢?
回答这个问题,主要要看写完的脏块会如何处理。
如果脏块从检查点队列中写到磁盘,脏块在LRU、LRUW链表的位置,不会任何变化,这一点很容易证明:

SQL> select dbms_rowid.ROWID_RELATIVE_FNO(rowid),dbms_rowid.rowid_block_number(rowid),id1,id2 from a2_70m where id1<=1;

DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)        ID1        ID2
------------------------------------ ------------------------------------ ---------- ----------
                                   4                                   20          1         10
我从A2_70M选择一行,它在4号文件20号块。
然后用如下语句观察x$bh中它的状态:
set pagesize 50000
set linesize 10000
select file#,dbablk,tch,lru_flag,ba,decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi',
9,'memory',10,'mwrite',11,'donated'),
decode(bitand(flag,1), 0, 'N', 'Y') dirty,US_NXT,US_PRV,LRU_FLAG from x$bh a where file#=4 and dbablk=20
order by      FILE#  ,   DBABLK;
结果如下:
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- --------
         4         20          2          0 80AEA000 xcur    N 80BF6694 80BF6694        0
从Dirty列可以看到,它并不是一个脏块。下面修改它:
SQL> update a2_70m set id2=id2+0 where id1=1;
1 row updated.
再次查看:
22:28:54 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- --------
         4         20          2          0 80AEA000 xcur    Y 80BF6694 80BF6694        0
已经是个脏块了。LRU_FLAG为0,说明它在主LRU上。这是因为ID1列上有索引,更新产生的读操作,是非全表扫描,所以它被放在主LRU上。全
表扫描的块,将被保留在辅助LRU中。
将增量检查点改的频繁些:
SQL> alter system set log_checkpoint_timeout=5;
System altered.
5秒一次,很快的,4号文件20号块已经不是脏块了,这是观察结果:
22:31:18 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- --------
         4         20          2          0 80AEA000 xcur    N 80BF6694 80BF6694        0
虽然不是脏块了,但它的LRU_FLAG列值,US_NXT、US_PRV列值,都没有变化。
这说明脏块虽然被写到磁盘中了,但它在Buffer Cache众链表中的位置,没有变化。

再来看看从LRUW中写出的情况,将log_checkpoint_timeout重新改回很大的值:
SQL> alter system set log_checkpoint_timeout=100000;
System altered.
再次修改4号文件20号块:
SQL> update a2_70m set id2=id2+0 where id1=1;
1 row updated.
确认它已经是脏块了:
22:43:39 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- --------
         4         20          1          0 80AEA000 xcur    Y 80BF6694 80BF6694        0
下面将a4_70m改为CACHE。目的是让它可以进入主LRU:
SQL> alter table lhb.a4_70m cache;
Table altered.
全扫描一个a4_70m:
select count(*) from a4_70m;

再来观察4号文件20号块:
22:51:21 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- --------
         4         20          1          4 7B72E000 xcur    N 7B7F7E7C 7B7F7E7C        4
已经不是脏块了,但它的LRU_FLAG列值为4,说明它已经被移到辅助LRU中了。并且,它的US_NXT、US_PRV列指针也都变化了。
这就是从检查点队列和从LRUW写脏块的最大区别,从检查点队列写完脏块,脏块只是变的不脏了,其他没有任何变化。但从LRUW写完脏块,块
要被放入辅助LRU,这样,块将会被很快覆盖掉。
Oracle之所设计两种写脏块模式,就是为了应对脏块较多的紧急情况。此时如果还从检查点队列写,辅助LRU中的块数量不会增加,前台进程还
是无法快速找到可用块。如果从LRUW写,写完的块被放入辅助LRU,只要这些脏块的TCH值不超过2,它们马上就可以被其他进程重用。
好了,关于LRUW,还有一个问题,我刚才的实验,update a2_70m set id2=id2+0 where id1=1; ,这条语句,会将块放在主LRU中,如果块在
辅助LRU中,又会怎样呢?下面来测试下:
先全扫描a2_70m:
SQL> select * from a2_70m;
此时查看4号文件20号块:
22:56:11 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   WA_NXT   WA_PRV     LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- -------- -------- ----------
         4         20          1          4 7C6C2000 xcur    N 7C7F5884 7C7F5884 7C7F588C 7C7F588C          4
LRU_FLAG为4,代表它在辅助LRU中,因为还没有修改,所以它不是一个脏块。
执行Update:
SQL> update a2_70m set id2=id2+0 where id1=1;
1 row updated.
再查看4号文件20号块的状态:
22:56:12 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   WA_NXT   WA_PRV     LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- -------- -------- ----------
         4         20          2          4 7C6C2000 xcur    Y 7C7F5884 7C7F5884 7C7F588C 7C7F588C          4
已经是脏块了,但LRU_FLAG仍为4,仍在辅助LRU中。
好,已经达到我们的目的,在辅助LRU中制造一个脏块。
下面全扫描a3_70m,在辅助LRU中占用大量块。4号文件20号块会被覆盖吗:
22:56:28 SQL> /
     FILE#     DBABLK        TCH   LRU_FLAG BA       DECODE( D US_NXT   US_PRV   WA_NXT   WA_PRV     LRU_FLAG
---------- ---------- ---------- ---------- -------- ------- - -------- -------- -------- -------- ----------
         4         20          0          8 7C6C2000 xcur    Y 7C7F5884 7C7F5884 7C7F588C 7C7F588C          8
没有被覆盖,LRU_FLAG状态为8,说明已经移到主LRU热端了。这是因为它的TCH值大于、等于2。但它仍是脏块。


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

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

注册时间:2013-02-28

  • 博文量
    231
  • 访问量
    823715