晶晶实验十八之buffer cache中的ＬＲＵ链

晶晶小妹

晶晶实验十八之buffer cache中的ＬＲＵ链

一、LRU链介绍
HASH是快速查找时，常用的算法。Oracle中几乎在所有需要快速查找的地方，都使用了HASH算法。LRU则是在“资源重用”时，常用的算法。
       在Buffer cache中，LRU链被分为两半，分别是热端、冷端，在默认方式下，热、冷端各占50%的块，这点可以由隐藏参数_db_percent_hot_default控制。当块第一次被读进Buffer时，会被插入到冷端头位置处。每次需要自由块时，Oracle服务器进程从冷端尾开始搜索可以被重用的块，因此，冷端的块是最有可能被重用的。在每个块的Buffer header中，准备有一个量，记录块被访问的次数，称作：Touch Count（TCH）。它代表块的访问频率。Oracle通过它决定块的冷热位置。在DSI中，专门有一段伪码，介绍TCH和块的重用：

关于Touch Count值具体算法如下：
IF ( 当前块的touch count 数> _db_aging_hot_criteria ) THEN
    此块暂不重用

IF (_db_aging_stay_count >= _db_aging_hot_criteria) THEN
        将此块的Touch Count数减半

ELSE


将此块的Touch Count值传给_db_aging_stay_count

END IF
ELSE

    此块将被重用
END IF
（上述伪码来自DSI）
       其中，_db_aging_hot_criteria与_ db_aging_stay_count都是Oracle的隐含参数，_db_aging_hot_criteria值默认为2，_ db_aging_stay_count有可能会随时变化。
       根据这段代码，假如说，又有新的物理读发生了，Buffer cache中已经没有了空块，服务器进程开始从LRU的冷端开始扫描，寻找可以被重用的自由块。
例如，LRU冷端第一个块的TCH值为4，而当前_db_aging_hot_criteria参数仍为默认值2。因为块的TCH为4，大于2，此块暂不重用。假如_db_aging_stay_count当前值为0，_db_aging_stay_count并不大于等于_db_aging_hot_criteria，因此，将此块的Touch Count值传给_db_aging_stay_count，当前_db_aging_stay_count的值变为了4。
       第一个块不可重用，继续向后查找。假如第二个块的TCH也为4，跟据上面的算法，它也不会被重用，但此时由于_db_aging_stay_count的值已经变为了4，已经大于_db_aging_hot_criteria的值2，因此，此块的TCH值将被减半，变为2。
       等等，服务器进程照此算法扫描LRU上的块，直到找到足够的自由块为止。
       但是这段伪码和我试验的结果一直不符。我试验的结果，每当块的TCH值发生变化时，并不会立即改变它所处的位置。块一旦从冷端移到了热端，TCH值马上变为0。
具体是，服务器进程需要读块进Buffer，它会从LRU链的尾端开始搜索自由块，如果发现搜索到的块的TCH值小于2，就重用这个块，并把它移动到冷端头。如果发现TCH大于2的块，并不会重用它，而是把它移到热端头部，并把它的TCH设为0。下面，我们试验一下这个过程：

晶晶小妹

步1：改变12号文件7号块的TCH值：
先确定一下，此块目前并不在Buffer cache中：
SQL> select lru_flag,tch from x$bh where dbablk=12 and dbarfil=7;

未选定行
然后，通过ROWID显示12号文件7号块中的任意一行。（可以只接用ROWID作为条件，也可以使用索引）
SQL> select id from jj_1 where rowid='AAAMt2AAHAAAAAMAAA';

ID
----------
1

再看一下12号文件7号块的TCH值：
SQL> select lru_flag,tch from x$bh where dbablk=12 and dbarfil=7;

LRU_FLAG　　　TCH

---------- 　　　----------
0　　　　　　　　1

已经是1了。LRU_FLAG列是此块目前在LRU链表中的位置。当此值为8或9时，代表块已经被送进热端。
此时，12号文件7号块当前被添加到了11的位置处：



每隔三秒，重复执行9遍如下命令：
SQL> select id from jj_1 where rowid='AAAMt2AAHAAAAAMAAB';
ID
----------
8

此时12号文件7号块的TCH值应该已经是10了，再显示一下：
SQL> select lru_flag,tch from x$bh where dbablk=12 and dbarfil=7;
LRU_FLAG　　TCH
---------- ----------
0　　　　　10
可以看到，已经是10了。但是，LRU_FLAG列仍是0。块并不会被移动到热端。
此时12号文件7号块的情况如下：





除TCH变为10外，12号文件7号块并不会被移到热端。

晶晶小妹

步2：在另一个表以索引方式扫描若干行：
SQL> select /*+index(qsmed.zjj1) */ * from qsmed.zjj1 where id>=1750 and id<=3500;
已选择1751行。

执行计划
----------------------------------------------------------
Plan hash value: 2538640105
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |  1772 |   164K|    31   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ZJJ1    |  1772 |   164K|    31   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | ZJJ1_ID |  1772 |       |     6   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("ID">=1750 AND "ID"<=3500)
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        263  consistent gets
         25  physical reads
          0  redo size
     165015  bytes sent via SQL*Net to client
       1661  bytes received via SQL*Net from client
        118  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       1751  rows processed
这有25个物理读。为了为这25个物理读寻找可用块，服务器进程将从LRU的末端，寻找可用块，将ZJJ1相关的块的信息覆盖这些可用块。并将它们从LRU的冷端末尾，移到冷端头。
显示12号文件7号块，不会有任何变化：
SQL> select lru_flag,tch from x$bh where dbablk=12 and dbarfil=7;
  LRU_FLAG        TCH                                                           
---------- ----------                                                           
         0         10                                                           
ZJJ1的25个物理读，目前还没有对12号文件7号块的状态有任何的影响，只不过，12号文件7号块被挤了向冷端末尾：



上图中ZJJ_1只占了4个格，这是不精确的，ZJJ_1和其索引应该占至少25个块才对，因为物理读有25个块。

晶晶小妹

步3：进一步加大从ZJJ_1扫描的行数：
SQL> select /*+index(qsmed.zjj1) */ * from qsmed.zjj1 where id<=7000;
已选择7000行。

执行计划
----------------------------------------------------------
Plan hash value: 2538640105
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         |  7060 |   654K|   116   (1)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ZJJ1    |  7060 |   654K|   116   (1)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | ZJJ1_ID |  7060 |       |    18   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("ID"<=7000)
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1034  consistent gets
         50  physical reads
          0  redo size
     668076  bytes sent via SQL*Net to client
       5511  bytes received via SQL*Net from client
        468  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       7000  rows processed
显示12号文件7号块，不会有任何变化：
SQL> select lru_flag,tch from x$bh where dbablk=12 and dbarfil=7;
  LRU_FLAG        TCH                                                           
---------- ----------                                                           
         0         10                                                           
当前的状态可以近似的用如下的图表示：

晶晶小妹

步4：再加大扫描的行数：
SQL> select /*+index(qsmed.zjj1) */ * from qsmed.zjj1 where id<=17500;
已选择17500行。

执行计划
----------------------------------------------------------
Plan hash value: 2538640105
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         | 17683 |  1640K|   287   (1)| 00:00:02 |
|   1 |  TABLE ACCESS BY INDEX ROWID| ZJJ1    | 17683 |  1640K|   287   (1)| 00:00:02 |
|*  2 |   INDEX RANGE SCAN          | ZJJ1_ID | 17683 |       |    42   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("ID"<=17500)
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       2589  consistent gets
        116  physical reads
          0  redo size
    1794670  bytes sent via SQL*Net to client
      13211  bytes received via SQL*Net from client
       1168  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      17500  rows processed
这一次12号文件7号块的位置和状态发生了变化，
SQL> select lru_flag,tch from x$bh where dbablk=12 and dbarfil=7;
  LRU_FLAG        TCH                                                           
---------- ----------                                                           
         8          0                                                           
LRU_FLAG的值变为了8，TCH列被清零。这说明12号文件7号块被移到了热端。原来方格10所代表的块不再属于热端，已被挤到了冷端。

ILoveMK

恕我直言，你在这里发这么高深的东西估计没有多少人会认真看，可能是因为这里的数据库高手比较少吧，去itpub发估计会引来一番热烈讨论的

doni

原帖由 ILoveMK 于 2008-10-16 10:40 发表
恕我直言，你在这里发这么高深的东西估计没有多少人会认真看，可能是因为这里的数据库高手比较少吧，去itpub发估计会引来一番热烈讨论的

氛围是逐渐培养起来的

晶晶小妹

...那什么东西在这里会比较引起 热烈点的讨论呢
比如说什么类型的课题?

lasama

这里的人一般都懂一些oracle，但是专做DBA或oracle服务的人不是很多。。。。

我比较关注的是oracle包括RAC,DATAGUARD在各种环境中如何较好地规划，如何提高稳定性，在项目中更好地使用

cssweb234

严重支持一下。18篇都收藏了。