shared pool 和buffer pool 详解（之二， Cache Buffers LRU Chain、Cache Buffers LRU Chain闩锁竞争与解决）

【深入解析--eygle】学习笔记

 

1.1.2  Cache BuffersLRU Chain闩锁竞争与解决

 

当用户进程需要读数据到Buffer Cache时或Cache Buffer根据LRU算法进行管理等，就不可避免的要扫描LRU  List获取可用Buffer或更改Buffer状态，我们知道，Oracle的Buffer Cache是共享内存，可以为众多并发进程并发访问，所以在搜索的过程中必须获取Latch（Latch是Oracle的一种串行锁机制，用于保护共享内存结构），锁定内存结构，防止并发访问损坏内存中的数据（我们必须认识到对于数据的访问、Buffer的存取就意味着多次的Latch访问，而过于严重的Latch竞争常常是系统的瓶颈所在）。

这个用于锁定LRU的Latch就是我们经常见到的Cache Buffers Lru Chain。

 

select addr, latch#,name, gets, misses, immediate_gets, immediate_misses

  from v$latch

 where name = 'cache buffers lru chain';

 

16:48:46 sys@felixSQL>select addr, latch#, name, gets, misses, immediate_gets,immediate_misses

17:19:05   2   from v$latch

17:19:05   3  where name = 'cache buffers lru chain';

 

ADDR                 LATCH# NAME                        GETS     MISSES IMMEDIATE_GETS IMMEDIATE_MISSES

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

0000000060019F08        150 cache buffers lru chain    29129          2          25156                0

 

17:19:06 sys@felix SQL>

 

可以从v$latch_children视图察看当前各子Latch使用情况：

 

select addr,

      child#,

       name,

       gets,

      misses,

      immediate_gets   igets,

       immediate_missesimisses

  fromv$latch_children

 where name= 'cache buffers lru chain';

 

17:19:06 sys@felix SQL>select addr,

17:46:11  2         child#,

17:46:11  3         name,

17:46:11  4         gets,

17:46:11  5         misses,

17:46:11  6         immediate_gets   igets,

17:46:11  7         immediate_misses imisses

17:46:11  8    from v$latch_children

17:46:11  9   where name = 'cache bufferslru chain';

 

ADDR             CHILD# NAME                     GETS     MISSES      IGETS   IMISSES

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

0000000077572578      16 cache buffers lru chain      0         0          0          0

00000000775724B0      15 cache buffers lru chain     16         0          1          0

0000000077556FE0      14 cache buffers lru chain      0         0          0          0

0000000077556F18      13 cache buffers lru chain     16         0          1          0

000000007753BA48      12 cache buffers lru chain      0         0          0          0

000000007753B980      11 cache buffers lru chain     16         0          1          0

00000000775204B0      10 cache buffers lru chain      0         0          0          0

00000000775203E8       9 cache buffers lru chain     16         0          1          0

0000000077504F18       8 cache buffers lru chain      0         0          0          0

0000000077504E50       7 cache buffers lru chain     16         0          1          0

00000000774E9980       6 cache buffers lru chain      0         0          0          0

00000000774E98B8       5 cache buffers lru chain  29417         2      25624          0

00000000774CE3E8       4 cache buffers lru chain      0         0          0          0

00000000774CE320       3 cache buffers lru chain     16         0          1          0

00000000774B2E50       2 cache buffers lru chain      0         0          0          0

00000000774B2D88       1 cache buffers lru chain     16         0          1          0

                                                 

16 rows selected.                                   

 

17:46:13 sys@felix SQL>

 

如果该Latch竞争激烈，通常有如下方法可以采用：

 

（1）  适当增大BufferCache，这样可以减少读数据到Buffer Cache的机会，减少扫描Lru List的竞争。

（2）  可以适当增加LRULatch的数量，修改_db_block_lru_latches参数可以实现，但是该参数通常来说是足够的，除非在Oracle Support的建议下或确知该参数将带来的影响，否则不推荐修改。

（3）  通过多缓冲池技术，可以减少不希望的数据老化和全表扫描等操作对于Default池的冲击，从而可以减少竞争。

（4）  优化SQL，减少数据读取，从而减少对于LRU List的扫描。

 

2.1.3 Cache Buffer Chain闩锁竞争与解决

在LRU和Dirty List这两个内存结构之外，Buffer Cache的管理还存在另外两个重要的数据结构：Hash Bucket和Cache Buffer Chain。

 

1．Hash Bucket和Cache Buffer Chain

我们可以想象，如果所有的Buffer Cache中的所有Buffer都通过同一个结构管理，当需要确定某个Block在Buffer中是否存在时，将需要遍历整个结构，性能会相当低下。

为了提高效率，Oracle引入了Bucket的数据结构，Oracle把管理的所有的Buffer通过一个内部的Hash算法运算后存放到不同Hash Bucket中，这样通过Hash Bucket进行分割之后，众多的Buffer被分布到一定数量的Bucket之中，当用户需要在Buffer中定位数据是否存在时，只需要通过同样的算法获得Hash值，然后到相应的Bucket中查找少量的Buffer即可确定。

 

每个Buffer的存放的Bucket由Buffer的数据块地址（DBA，Data Block Address）运算决定。在Bucket内部，通过Cache Buffer Chain（它是一个双向链表）将所有的Buffer通过BufferHeader信息联系起来。

Buffer Header存放的是对应数据块的概要信息，包括数据块的文件号、块地址、状态等。在判断数据块在Buffer中是否存在，通过检查Buffer header即可确定。

 

让我们通过一个现实的场景来回顾一下这个过程。

如果大家去过老一点的图书馆，查找过手工索引，你可能记得这样的场景：树立在你面前的是一排柜子（那是相当的壮观），柜子又被分为很多小的抽屉，抽屉上按照不同的分类方法标注了相关信息，比如按开头字母顺序，如果我们要查询Oracle相关书籍，就需要找到标记有“O”的 抽 屉 。打 开 抽 屉 ，我们 会 看 到 一 系 列 的 卡 片 ，这 些 卡 片 通 常 被 一 根铁闩串起来（通常就是一个铁丝），每根卡片上会记录相关书籍的信息，可能包括书籍名称、作者、ISBN号、出版日期等，当然这些卡片上还存储了一个重要的信息，就是书籍存放的书架位置信息，有了这个信息，通过翻阅这些卡片，就可以快速地找到想要的书籍，并且 在 需 要 时 能 够 快 速 从 图 书

 

馆浩如烟海的图书中找到我们需要的一本。

 

在这里，图书馆就是我们的Buffer Cache，这个Cache可能因为“图书数量”的增加而不断扩大；每个抽屉都是一个Bucket，这个Bucket中存放了根据一定的分类方式（也就是通过Hash运算）归入的图书信息，也就是Buffer Header；抽屉中的每张卡片就是一个Buffer Header，这些Buffer  Header上记录了关于数据块的重要信息，如DBA等；这些卡片在Bucket中，通过一个铁闩串接起来，这就是Cache Buffer Chain

 

由于每个抽屉只有一根铁闩，如果很多同学都想翻阅这个链上的卡片，那么就产生了Cache  Buffer  Chain的竞争，先来到那个同学持有了Latch就能不停的翻阅，其他同学只好不停的来检查，当然如果检查次数多了（超过了_spin_count）， 也 可 以 去 休 息 室 小 憩 一 会 ， 再来和其他同学争夺。

从Oracle 9i开始,对于Cache Buffer Chain的只读访问，其Latch可以被共享。也就是说，如果大家都只是翻一翻卡片，那么大家可以一起读，但是如果有人要借走这本书，那么就只能独享这个Latch了。这就是Buffer Cache与Latch竞争。

 

由于Buffer根据Buffer  Header进行散列，最终决定存入那一个Hash  Bucket，那么Hash Bucket的数量在一定程度上决定了每个Bucket中Buffer数量的多少，也就间接影响了搜索的性能。所以在不同版本中，Oracle一直在修改算法，优化Hash Bucket的数量。我们可以想象， Bucket的数量多一些，那么在同一时间就可以有更多的同学可以拿到不同的抽屉，进行数据访问；但是更多的抽屉，显然需要更多的存放空间，更多的管理成本，所以优化在什么时候都不是简单的一元方程。

Hash Bucket的设置受一个隐含参数_ DB_BLOCK_HASH_BUCKETS的影响。在Oracle 7和Oracle 8中，该参数缺省值为DB_BLOCK_BUFFERS/4的下一个素数。

通过以上的讨论可以知道，对应每个Bucket，只存在一个Chain，当用户试图搜索Cache Buffer Chain时，必须首先获得Cache Buffer Chain Latch。那么Cache BufferChain Latch的设置就同样值得研究了

 

我们看到，从Oracle  8i 开始，_db_block_hash_buckets 的数量较以前增加了8 倍，而_db_block_hash_latchs的数量增加有限，这意味着，每个Latch需要管理多个Bucket，但是由于Bucket数量的多倍增加，每个Bucket上的Block数量得以减少，从而使少量Latch管理更多Bucket成为可能。

 

 

 

总结一下上图中所描述的内容。

（1）  从Oracle8i开始，Bucket的数量比以前大大增加；通过增加的Bucket的“稀 释 ”使得每个Bucket上的Buffer数量大大减少。

（2）  在Oracle8i之前，_db_block_hash_latches的数量和Bucket的数量是一致的，每个Latch管理一个Bucket；从Oracle 8i开始每个Latch需要管理多个Bucket，由于每个Bucket上的Buffer数量大大降低，所以Latch的性能反而得到了提高。

（3）  每个Bucket存在一条Cache Buffer Chain。

（4）  Buffer Header上存在指向具体Buffer的指针。

 

 

2．X$BH与Buffer Header

Buffer  Header数据，可以从数据库的字典表中查询得到，这张字典表是：X$BH。X$BH中的BH就是指Buffer Headers，每个Buffer在x$bh中都存在一条记录

 

Buffer  Header中存储每个Buffer容纳的数据块的文件号、块地址、状态等重要信息，可以将Buffer Header看作是Buffer的“名片”，通过这张名片，Buffer的重要信息得以展现;

下图包含了Buffer Header上记录的信息，Hash Bucket上的Chian连接起这些BH。

 

 

 

根据Buffer  Header上记录的这些信息，结合dba_extents视图，可以很容易地找到每个Buffer对应的对象信息：

 

12:01:56 SQL>desc v$bh;

 Name                    Null?    Type

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

 FILE#                            NUMBER

 BLOCK#                           NUMBER

 CLASS#                           NUMBER

 STATUS                           VARCHAR2(10)

 XNC                              NUMBER

 FORCED_READS                     NUMBER

 FORCED_WRITES                    NUMBER

 LOCK_ELEMENT_ADDR                RAW(8)

 LOCK_ELEMENT_NAME                NUMBER

 LOCK_ELEMENT_CLASS               NUMBER

 DIRTY                            VARCHAR2(1)

 TEMP                             VARCHAR2(1)

 PING                             VARCHAR2(1)

 STALE                            VARCHAR2(1)

 DIRECT                           VARCHAR2(1)

 NEW                              CHAR(1)

 OBJD                             NUMBER

 TS#                              NUMBER

 LOBID                            NUMBER

 CACHEHINT                        NUMBER

 

12:07:19 SQL>

 

 

X$BH中还有一个重要字段TCH，TCH为Touch的缩写，表征一个Buffer的访问次数， Buffer被访问的次数越多，说明该Buffer越“抢手”，也就可能存在热点块竞争的问题。

以下通过几个简单的查询。以下查询用于获得当前数据库最繁忙的Buffer：

 

SELECT *

  FROM(SELECT addr, ts#, file#, dbarfil, dbablk, tch

         FROM x$bh

        ORDER BY tch DESC)

 WHERE ROWNUM < 11;

 

 

 

再结合dba_extents中的信息，可以查询得到这些热点Buffer都来自哪些对象：

查询热点块对象：

sys@felix SQL>SELECT e.owner, e.segment_name,e.segment_type

     FROMdba_extents e,

         (SELECT *

            FROM (SELECT addr, ts#, file#, dbarfil, dbablk, tch

                     FROM x$bh

                   ORDER BY tch DESC)

           WHERE ROWNUM < 11) b

    WHEREe.relative_fno = b.dbarfil

      ANDe.block_id <= b.dbablk

      AND e.block_id + e.blocks > b.dbablk;

 

OWNER                 SEGMENT_NAME                   SEGMENT_TYPE

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

SYS                   C_USER#                        CLUSTER

SYS                   I_USER1                        INDEX

SYS                   JOB$                           TABLE

SYS                   JOB$                           TABLE

SYS                   SCHEDULER$_CLASS               TABLE

SYS                   SCHEDULER$_CLASS_PK            INDEX

SYS                   SCHEDULER$_JOB                 TABLE

SYS                   SCHEDULER$_JOB                 TABLE

SYS                   SCHEDULER$_JOB                 TABLE

SYS                  SCHEDULER$_LIGHTWEIGHT_JOB    TABLE

 

10 rows selected.

 

12:16:13 sys@felix SQL>

 

除了查询X$BH之外，其实也可以从Buffer Cache的转储信息中，看到Buffer Header的具体内容，以下信息来自Level 1级的Buffer Dump：

*** ACTION NAME:() 2014-07-23 13:58:11.585

 

Dump of buffer cache at level 1 for tsn=2147483647rdba=0

BH (0x69fd83a8) file#: 2 rdba: 0x00804d72(2/19826) class: 4 ba: 0x69c08000

  set: 3pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25

  dbwrid: 0obj: 58298 objn: -1 tsn: 1 afn: 2 hint: f

  hash:[0x77f8d3b0,0x77f8d3b0] lru: [0x69fd85c0,0x69fd8360]

  lru-flags:debug_dump on_auxiliary_list

  ckptq:[NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]

  st: CR md:NULL tch: 1

  cr: [scn:0x0.197ed5],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.198787],[sfl: 0x0],[lc:0x0.0]

  flags:

BH (0x6a3f1e88) file#: 1 rdba: 0x004084d5(1/34005) class: 1 ba: 0x6a2bc000

  set: 3pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25

  dbwrid: 0obj: 37 objn: 37 tsn: 0 afn: 1 hint: f

  hash:[0x77f8d3c0,0x77f8d3c0] lru: [0x6a3f20a0,0x6a3f1e40]

  lru-flags:debug_dump hot_buffer

  ckptq:[NULL] fileq: [NULL] objq: [0x6a3f20c8,0x6a3f1e68] objaq:[0x6a3f20d8,0x6a3f1e78]

  st:XCURRENT md: NULL fpin: 'kdiwh100: kdircys' tch: 3

  flags:only_sequential_access

  LRBA:[0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

BH (0x6d7de638) file#: 2 rdba: 0x008109aa(2/68010) class: 4 ba: 0x6d4ae000

  set: 3pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25

  dbwrid: 0obj: 71803 objn: -1 tsn: 1 afn: 2 hint: f

  hash:[0x77f8d3f0,0x77f8d3f0] lru: [0x6d7de5f0,0x6d7de850]

  lru-flags:debug_dump

  ckptq:[NULL] fileq: [NULL] objq: [NULL] objaq: [NULL]

  st: CR md:NULL tch: 1

  cr: [scn:0x0.197ed5],[xid: 0x0.0.0],[uba: 0x0.0.0],[cls: 0x0.199105],[sfl: 0x0],[lc:0x0.0]

  flags:

 

在Oracle 10g之前，数据库的等待事件中，所有Latch等待被归入Latch Free等待事件中，在Statspack的report中，如果在Top 5等待事件中看到Latch Free这一等待处于较高的位置，就需要DBA介入进行研究和解决。

 

3．热点块竞争与解决

接下来将通过一个环境的实际情况对热点块的问题进行分析和探讨。

Top 5等待事件都值得关注。注意到这个数据库中Latch Free是最严重的竞争。

由于Latch  Free是一个汇总等待事件，我们需要从v$latch视图获得具体的Latch竞争主要是由哪些Latch引起的。

如果cache buffers chains正是主要的Latch竞争。实际上，如果数据库在繁忙的时段，基本上处于停顿状态，大量进程等待latchfree竞争，这些获得Session的等待事件可以很容易地从v$session_wait视图中查询得到：

 

16:10:22 sys@felix SQL>select SID,EVENT,SEQ#from v$session_wait;

 

       SIDEVENT                                                             SEQ#

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

         1SQL*Net message to client                                          7166

         2pmon timer                                                        5913

         3rdbms ipc message                                                18352

         4 VKTM Logical Idle Wait                                               1

         5rdbms ipc message                                                 5912

         6DIAG idle wait                                                   17714

         7rdbms ipc message                                                 5923

         8DIAG idle wait                                                   17704

         9rdbms ipc message                                                 5913

        10rdbms ipc message                                                 9958

        11rdbms ipc message                                                11632

        12rdbms ipc message                                                22003

        13smon timer                                                          410

        14rdbms ipc message                                                   28

        15rdbms ipc message                                                 7335

        16rdbms ipc message                                                 17710

        18rdbms ipc message                                                  549

        20rdbms ipc message                                                  565

        21rdbms ipc message                                                  3404

        22rdbms ipc message                                                  546

        26Streams AQ: qmn coordinator idle wait                              1270

        28Streams AQ: waiting for time management or cleanup tasks              3

        30Streams AQ: qmn slave idle wait                                     712

        32rdbms ipc message                                                 5828

        33SQL*Net message from client                                         32

        35rdbms ipc message                                                 4902

        36SQL*Net message from client                                        7734

        37Space Manager: slave idle wait                                      125

        38Space Manager: slave idle wait                                      246

        40jobq slave wait                                                     54

        41jobq slave wait                                                     54

        45SQL*Net message from client                                         429

        47Space Manager: slave idle wait                                       65

 

33 rows selected.

 

16:10:30 sys@felix SQL>

 

如果需要具体确定热点对象，可以从v$latch_children中查询具体的子Latch信息：

SELECT *

  FROM(SELECT addr,

              child#,

              gets,

              misses,

              sleeps,

              immediate_gets   igets,

              immediate_misses imiss,

              spin_gets        sgets

         FROM v$latch_children

        WHERE NAME = 'cache buffers chains'

        ORDER BY sleeps DESC)

 WHEREROWNUM < 11;

_value,address, piece;

 

 

X$BH中还存在另外一个关键字段HLADDR，即Hash Chain Latch Address，这个字段可以和v$latch_child.addr进行关联，这样就可以把具体的Latch竞争和数据块关联起来，再结合dba_extents视图，就可以找到具体的热点竞争对象。

到具体热点竞争对象之后，可以进一步地结合v$sqlarea或者v$sqltext视图，找到频繁操作这些对象的SQL，对其进行优化，就可以缓解或解决热点块竞争的问题。通过以下查询可以实现以上的思想，获取当前持有最热点数据块的Latch及Buffer信息：

SELECT b.addr,

      a.ts#,

       a.dbarfil,

      a.dbablk,

      a.tch,

      b.gets,

      b.misses,

      b.sleeps

  FROM(SELECT *

         FROM (SELECT addr, ts#, file#, dbarfil, dbablk, tch, hladdr

                 FROM x$bh

                ORDER BY tch DESC)

        WHERE ROWNUM < 11) a,

      (SELECT addr, gets, misses, sleeps

         FROM v$latch_children

        WHERE NAME = 'cache buffers chains') b

 WHEREa.hladdr = b.addr;

 

ADDR                    TS#    DBARFIL    DBABLK        TCH       GETS    MISSES     SLEEPS

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

0000000077BF8A38          2          3        144        249       5274          0          0

0000000077FEF1F8          2          3        208        248       6702          0          0

0000000077F9FCF0          2          3        272        247       5198          0          0

0000000077FF0900          0          1       2017        246     15293          0          0

0000000077BD1018          2          3       176        245       5187          0          0

0000000077BE5128          2          3        160        245       5034          0          0

0000000077FC77D8          2          3        240        244       6431          5          3

0000000077BEEDB0          0          1       2016        244       9761          0          0

0000000077FDB0E8          2          3        224        244       6161          0          0

0000000077BBD708          2          3        192        242       5805          0         0

利用前面提到的SQL，可以找到这些热点Buffer的对象信息：

SELECT distinct e.owner, e.segment_name,e.segment_type

  FROMdba_extents e,

      (SELECT *

         FROM (SELECT addr, ts#, file#, dbarfil, dbablk, tch

                 FROM x$bh

                ORDER BY tch DESC)

        WHERE ROWNUM < 11) b

 WHEREe.relative_fno = b.dbarfil

   ANDe.block_id <= b.dbablk

   ANDe.block_id + e.blocks > b.dbablk;

 

16:18:29 sys@felix SQL>/

OWNER        SEGMENT_NAME                  SEGMENT_TYPE

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

SYS          _SYSSMU1_1240252155$          TYPE2 UNDO

SYS          _SYSSMU2_111974964$           TYPE2 UNDO

SYS          _SYSSMU5_4011504098$          TYPE2 UNDO

SYS          _SYSSMU9_3945653786$          TYPE2 UNDO

SYS          _SYSSMU6_3654194381$          TYPE2 UNDO

SYS          _SYSSMU4_1126976075$          TYPE2 UNDO

SYS          _SYSSMU8_3612859353$          TYPE2 UNDO

SYS          _SYSSMU10_3271578125$         TYPE2 UNDO

SYS          _SYSSMU3_4004931649$          TYPE2 UNDO

SYS          _SYSSMU7_4222772309$          TYPE2 UNDO

 

10 rows selected.

 

16:25:56 sys@felix SQL>

 

 

结合v$sqltext或v$sqlarea，可以找到操作这些对象的相关SQL，让我们继续查询：

 

 

break on hash_value skip 1

 

 

SELECT /*+ rule */

 hash_value,sql_text

  FROMv$sqltext

 WHERE(hash_value, address) IN

      (SELECT a.hash_value, a.address

         FROM v$sqltext a,

              (SELECT DISTINCT a.owner, a.segment_name, a.segment_type

                 FROM dba_extents a,

                       (SELECT dbarfil, dbablk

                          FROM (SELECT dbarfil,dbablk

                                  FROM x$bh

                                 ORDER BY tchDESC)

                         WHERE ROWNUM < 11)b

                WHERE a.relative_fno = b.dbarfil

                  AND a.block_id <= b.dbablk

                  AND a.block_id + a.blocks > b.dbablk) b

        WHERE upper(a.sql_text) LIKE '%' || b.segment_name || '%'

          AND b.segment_type = 'TABLE')

 ORDER BYhash_value, address, piece;

 

 

找到这些SQL之后，剩下的问题就简单了，可以通过优化SQL减少数据的访问，避免或优化某些容易引起争用的操作（如connect by等操作）来减少热点块竞争。