深度分析数据库的热点块问题

 

热点块的定义

        数据库的热点块，从简单了讲，就是极短的时间内对少量数据块进行了过于频繁的访问。定义看起来总是很简单的，但实际在数据库中，我们要去观察或者确定热点块的问题，却不是那么简单了。要深刻地理解数据库是怎么通过一些数据特征来表示热点块的，我们需要了解一些数据库在这方面处理机制的特性。

数据缓冲区的结构

        我们都知道，当查询开始的时候，进程首先去数据缓冲区中查找是否存在查询所需要的数据块，如果没有，就去磁盘上把数据块读到内存中来。在这个过程中，涉及到数据缓冲区中LRU链的管理（8i开始以接触点计数为标准衡量buffer冷热从而决定buffer是在LRU的冷端还是热端），关于这部分内容，从oracle concepts 中就能得到详尽的文档，我不准备去论述这部分内容，这也不是本文的重点。现在我们的重点是，到底进程是如何地去快速定位到自己所想要的block的，或者如何快速确定想要的block不在内存中而去进行物理读的。

        我们仔细想一想，随着硬件的发展，内存越来越大，cache buffer也越来越大，我们如何才能在大量的内存中迅速定位到自己想要的block？总不能去所有buffer中遍历吧！在此数据库引出了hash的概念（oracle中快速定位信息总是通过hash算法的，比如快速定位sql是否在shared pool size中存在就是通过hash value来定位的，也就是说shared pool size中对象也是通过hash table来管理的），了解一点数据结构的基本知识就知道，hash 的一大重要功能就是快速地查找。举个最简单的例子，假设我们有一个hash table 就是一个二维数组a[200][100],现在有1000个无序数字，我们要从这1000个数字里面查找某个值是否存在，或者说当我们接收到某个数字的时候必须判断是否已经存在，当然，我们可以遍历这1000个数字，但这样的效率就很低。但现在我们考虑这样一种方法，那就是把1000个数字除以200，根据其余数，放在a[200][100]里面(假设相同余数的最大数量不超过100)，余数就是数组的下标。这样，平均来说一个数组a[i]里面可能有5个左右的数字。当我们要去判别一个数字是否存在的时候，对这个数字除以200(这就是一个最简单的hash算法)，根据余数i作为下标去数组a[i]中查找，大约进行5次查找就能判别是否已经存在，这样通过开辟内存空间a[200][100]来换取了时间(当然hash 算法的选取和hash table的大小是一个很关键的问题)。

        明白了基本的hash原理之后，我们再来看oracle的block的管理。数据库为这些block也开辟了hash table，假设是a,则在一维上的数量是由参数_db_block_hash_buckets 来决定的，也就是存在hash table a[_db_block_hash_buckets ],从oracle8i开始，_db_block_hash_buckets =db_block_buffers*2。而一个block被放到哪个buckets里面，则是由block的文件编号、块号(x$bh.dbarfl、x$bh.dbablk对应了block的文件属于表空间中的相关编号和block在文件中的编号，x$bh是所有cache buffer的header信息，通过表格的形式可以查询)做hash 算法决定放到哪个bucket的，而bucket里面就存放了这些buffers的地址。这样当我们要访问数据的时候，可以获得segment的extent(可以通过dba_extents查到看，详细的信息来源这里不做探讨)，自然知道要访问的文件编号和block编号，根据文件和block编号可以通过hash算法计算出hash bucket,然后就可以去hash bucket里面去找block对应的buffer。

        除此之外，为了维护对这些block的访问和更改，oracle还提供了一种latch来保护这些block。因为要避免不同的进程随意地径直并发修改和访问这些block，这样很可能会破坏block的结构的。latch是数据库内部提供的一种维护内部结构的一种低级锁，latch的生存周期极短(微秒以下级别)，进程加latch后快速的进行某个访问或者修改动作然后释放latch(关于latch不再过多的阐述，那可能又是需要另一篇文章才能阐述清楚)。这种latch数量是通过参数_db_block_hash_latches 来定义的，一个latch对应的保护了多个buckets。从8i开始，这个参数的default规则为:

当cache buffers 少于2052 buffers

_db_block_hash_latches  =  power(2,trunc(log(2, db_block_buffers - 4) - 1))

当cache buffers多于131075 buffers

_db_block_hash_latches  =  power(2,trunc(log(2, db_block_buffers - 4) - 6))

当cache buffers位于2052与131075 buffers之间

_db_block_hash_latches  =  1024

        通过这个规则我们可以看出，一个latch大约可以维护128个左右的buffers。由于latch使得对block的操作的串行化(9i中有改进，读与读可以并行，但读与写、写与写依然要串行)，很显然我们可以想到一个道理，如果大量进程对相同的block进程进行操作，必然在这些latch上造成竞争，也就是说必然形成latch的等待。这在宏观上就表现为系统级的等待。明白了这些原理，为我们下面的在数据库中的诊断奠定了基础。

如何确定热点对象

            如果我们经常关注statspack报告，会发现有时候出现cache buffer chains的等待。这个cache buffer chains就是_db_block_hash_latches所定义的latch的总称，通过查询v$latch也可得到：

select">sys@OCN>select  latch#,name,gets,misses,sleeps from v$latch where name   like 'cache buffer%';

    LATCH# NAME                                 GETS     MISSES     SLEEPS
---------- ------------------------------ ---------- ---------- ----------
        93 cache buffers lru chain          54360446      21025        238
        98 cache buffers chains           6760354603    1680007      27085
        99 cache buffer handles               554532          6                   0

  在这个查询结果里我们可以看到记录了数据库启动以来的所有cahce buffer chains的latch的状况，gets表示总共有这么多次请求，misses表示请求失败的次数(加锁不成功)，而sleeps 表示请求失败休眠的次数，通过sleeps我们可以大体知道数据库中latch的竞争是否严重，这也间接的表征了热点块的问题是否严重。由于v$latch是一个聚合信息，我们并不能获得哪些块可能存在频繁访问。那我们要来看另一个view信息，那就是v$latch_children,v$latch_children.addr记录的就是这个latch的地址。

select">sys@OCN>select addr,LATCH#,CHILD#,gets,misses,sleeps from v$latch_children
  2  where name = 'cache buffers chains'  and rownum < 21;

ADDR         LATCH#     CHILD#       GETS     MISSES     SLEEPS
-------- ---------- ---------- ---------- ---------- ----------
91B23B74         98       1024   10365583       3957         33
91B23374         98       1023    5458174        964         25
91B22B74         98       1022    4855668        868         15
91B22374         98       1021    5767706        923         22
91B21B74         98       1020    5607116        934         31
91B21374         98       1019    9389325       1111         25
91B20B74         98       1018    5060207        994         31
91B20374         98       1017   18204581       1145         18
91B1FB74         98       1016    7157081        920         23
91B1F374         98       1015    4660774        922         22
91B1EB74         98       1014    6954644        976         32
91B1E374         98       1013    4881891        970         19
91B1DB74         98       1012    5371135        971         28
91B1D374         98       1011    5154497        990         26
91B1CB74         98       1010    5013796        936         18
91B1C374         98       1009    5667446        939         25
91B1BB74         98       1008    4673421        883         14
91B1B374         98       1007    4589646        986         17
91B1AB74         98       1006   10380781       1020         20
91B1A374         98       1005    5142009       1110         19

20 rows selected.

到此我们可以根据v$latch_child.addr关联到对应的x$bh.hladdr(这是buffer header中记录的当前buffer所处的latch地址)，通过x$bh可以获得块的文件编号和block编号。

select">sys@OCN>select dbarfil,dbablk 
    from x$bh
   where hladdr in
    (select addr
    from (select addr
        from v$latch_children
        order by sleeps desc) 
          where rownum < 11);

   DBARFIL     DBABLK
---------- ----------
         4       6498
        40      14915
        15      65564
        28      34909
        40      17987
         1      24554
         8      21404
        39      29669
        28      46173
        28      48221

……………………

      由此我们就打通了cache buffers chains和具体block之间的关系，那再继续下来，知道了block，我们需要知道究竟是哪些segment。这个可以通过dba_extents来获得。

select distinct a.owner,a.segment_name from
dba_extents a,
(select dbarfil,dbablk
from x$bh
where hladdr in
    (select addr
    from (select addr
        from v$latch_children
        order by sleeps desc)
        where rownum < 11)) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;

OWNER                          SEGMENT_NAME                   SEGMENT_TYPE
------------------------------ ------------------------------         ------------------
ALIBABA                        BIZ_SEARCHER                               TABLE
ALIBABA                        CMNTY_USER_MESSAGE             TABLE
ALIBABA                        CMNTY_VISITOR_INFO_PK          INDEX
ALIBABA                        COMPANY_AMID_IND                   INDEX
ALIBABA                        COMPANY_DRAFT                         TABLE
ALIBABA                        FEEDBACK_POST                           TABLE
ALIBABA                        IM_BLACKLIST_PK                         INDEX
ALIBABA                        IM_GROUP                                        TABLE
ALIBABA                        IM_GROUP_LID_IND                      INDEX
ALIBABA                        MEMBER                                           TABLE
ALIBABA                        MEMBER_PK                                    INDEX
ALIBABA                        MLOG$_SAMPLE                            TABLE

……………………

  我们还有另外一种方式

   select object_name
from dba_objects
where data_object_id in
(select obj
from x$bh
where hladdr in
    (select addr
    from (select addr
        from v$latch_children
        order by sleeps desc)
        where rownum < 11)) ;

OBJECT_NAME
------------------------------------
I_CCOL2
RESOURCE_PLAN$
DUAL
FGA_LOG$
AV_TRANSACTION
COMPANY_DRAFT
MEMBER
SAMPLE
SAMPLE_GROUP
VERTICAL_COMPONENT
MEMBER_PK
SAMPLE_GROUP_PK
IM_BLACKLIST_PK
IM_CONTACT
IM_GROUP
CMNTY_USER_MESSAGE
CMNTY_VISITOR_INFO_PK
IM_OFFLINEMSG_TID_IND
OFFER
OFFER_PK
OFFER_EMAIL_IND
OFFER_DRAFT
CMNTY_USER_MESSAGE_TD_BSM_IND
CMNTY_MESSAGE_NUM_PK
BIZ_EXPRESS_MEMBER_ID_IND

……………………

 

 

        到这里我们基本能找到热点块对对应的对象。但实际上还有另外一个途径来获取这些信息，那就是和x$bh.tch 相关的一种方法。对于8i开始oracle提供了接触点(touch count)来作为block是冷热的标志，在一定条件满足的情况下block被进程访问一次touch count 增加一，到某个标准之后被移动到LRU热端(关于touch count 在这里不做详细介绍，那又将是一大篇文章)。那在短时间内从某种意义上讲，touch count 大的block可能暗示着在当前某个周期内被访问次数比较多。

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 tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;

OWNER                          SEGMENT_NAME                   SEGMENT_TYPE
------------------------------ ------------------------------         ------------------
ALIBABA                        CMNTY_USER_MESSAGE              TABLE
ALIBABA                        MEMBER_PK                                      INDEX
ALIBABA                        OFFER_DRAFT_GMDFY_IND          INDEX

同上面一样还有这个方法

select object_name
from dba_objects
where data_object_id in
(select obj
from (select obj
    from x$bh order by tch desc) where rownum < 11) ;
OBJECT_NAME
---------------------------------------------------
DUAL
MEMBER_PK
SAMPLE_GROUP_PK
CMNTY_USER_MESSAGE_TD_BSM_IND
OFFER_DRAFT_MID_GMDFY_IND
OFFER_MID_GPOST_IND
OFFER_DRAFT_PK
MEMBER_GLLOGIN_IND
OFFER_MID_STAT_GEXPIRE_IND
SAMPLE_MID_STAT_IND

10 rows selected.

 

        到这里，我们寻找热点块和热点对象的工作算是完成了，但我们还并没有解决问题。

 

热点问题的解决

           热点块和热点对象我们都找到了，但是我们该怎么来解决这个问题呢？一般来说，热点块会导致cache buffers chains竞争等待，但并不是说cache buffer chains一定是因为热点块而起，在特别情况下有可能是因为latch数量的问题导致的，也就是一个latch管理的buffers数量太多而导致竞争激烈。但是latch数量我们一般是不会轻易去设置的，这是oracle的隐藏参数。

          实际上最有效的办法，是从优化sql入手，不良的sql往往带来大量的不必要的访问，这是造成热点块的根源。比如本该通过全表扫描的查询却走了索引的range scan，这样将带来大量的对块的重复访问。从而形成热点问题。再或者比如不当地走了nested loops的表连接，也可能对非驱动表造成大量的重复访问。那么在这个时候，我们的目标就是找出这些sql来并尝试优化。在statspack报告中，根据报告中sql列表，我们如果是通过dba_extents确定的热点对象而不是通过dba_objects确定的，则可以通过查找出的热点segment转换为对应的表，对于非分区的索引，index_name就是segment_name,通过dba_indexes很容易的找到对应的table_name,对于分区表和分区索引也能通过和dba_tab_partition和dba_ind_partitions找到segment和table的对应关系。通过这些table到statspack报告中去找相关的sql。

select sql_text
from stats$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 tch desc) 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 a.sql_text like '%'||b.segment_name||'%' and b.segment_type = 'TABLE'
order by  a.hash_value,a.address,a.piece;

SQL_TEXT
----------------------------------------------------------------
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT bizgroup.seq_grp_post.NextVal FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
SELECT bizgroup.seq_grp_user.NextVal FROM DUAL
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
select seq_Company_Draft.NextVal from DUAL
SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
SELECT SYSDATE FROM DUAL
select seq_News_Forum.NextVal from DUAL
SELECT SEQ_SMS_USER.nextval FROM DUAL
select seq_Biz_Member.NextVal from DUAL
select seq_Pymt_Managing.NextVal from DUAL
E= '+08:00' NLS_DUAL_CURRENCY = '$' NLS_TIME_FORMAT = 'HH.MI.SSX
SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
SELECT 1 FROM DUAL
select seq_offer_draft.NextVal from DUAL
select seq_Biz_Express_Category.NextVal from DUAL

20 rows selected.

当然这里是从statspack搜集的stats$sqltext中去找的(你可以在statspack的文本报告中去找)，实际上，我们可以直接在当前数据库中的v$sqlarea或者v$sqltext里面去找到这些sql，然后来尝试优化。

select sql_text
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 tch desc) 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 a.sql_text like '%'||b.segment_name||'%' and b.segment_type = 'TABLE'
order by  a.hash_value,a.address,a.piece;
SQL_TEXT
----------------------------------------------------------------
SELECT NULL FROM DUAL FOR UPDATE NOWAIT
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT SEQ_IM_GROUP.nextval FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
='DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRENCY='$' NLS_COMP='
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRENCY='$' NLS_COMP='BI
SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
SELECT SYSDATE FROM DUAL
SELECT SEQ_SMS_USER.nextval FROM DUAL
IMESTAMP_TZ_FORMAT='DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRE
SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
SELECT 1 FROM DUAL
SELECT USER FROM DUAL
SELECT DECODE('A','A','1','2') FROM DUAL

18 rows selected.

    除了优化sql外，当然对于热点的表或者索引来说，如果小的话，我们可以考虑cache在内存中，这样可能降低物理读提高sql运行速度(这并不会减少cache buffer chains的访问次数)，对于序列，我们可以对序列多设置一些cache。如果是并行服务器环境中的索引对象，并且这个索引是系列递增类型，我们可以考虑反向索引(关于反向索引这里就不过多地做介绍了)。

热点块的其他相关症状

        在数据库中还可能存在一些其他方面的热点块症状，通过v$waitstat的等待可以看出一些端倪,v$waitstat是根据数据缓冲区中各种block的类型(x$bh.class)而分类统计的等待状况。

select">sys@OCN>select * from v$waitstat;

CLASS                   COUNT       TIME
------------------ ---------- ----------
data block            1726977     452542
sort block                  0          0
save undo block             0          0
segment header             40         11
save undo header            0          0
free list                   0          0
extent map                  0          0
1st level bmb             611        112
2nd level bmb              42         13
3rd level bmb               0          0
bitmap block                0          0
bitmap index block          0          0
file header block          13         92
unused                      0          0
system undo header        111         28
system undo block           7          0
undo header              2765        187
undo block                633        156

比如在ASSM表空间出现之前，由于freelist的存在，如果表经常被并发的进程DML，则可能存在大量的data block的等待，或者有free list的等待。那么这个时候我们发现这样的segment之后需要考虑增加freelist数量。再比如经常发生长时间的DML的表被频繁地访问，这样将会造成过多的对回滚段中块的访问，这时可能undo  block 的等待会比较多。那么我们可能需要控制DML的时间长度或者想办法从应用程序入手来解决问题。如果是undo header的等待比较多，没使用undo tablespace 之前，可能需要考虑增加回滚段的数量。

总结

      本文从热点块的原理入手，详细地由oracle的内部结构特征开始介绍了热点块的产生和表现特征。进而阐述了诊断热点对象和找出造成热点对象的sql的方法。并从解决热点问题方面提供了解决方向。

posted on 2004年07月06日 12:51 PM

Comments

·                                 # 回复：深度分析数据库的热点块问题

MIT
Posted @ 2004-07-08 1:11 AM

除了优化sql外，当然对于热点的表或者索引来说，如果小的话，我们可以考虑cache在内存中，


cached in memory would cause buffer cache chains again?

·                                 # 回复：深度分析数据库的热点块问题

biti_rainy
Posted @ 2004-07-08 9:12 AM
cache 在 内存中依然会有 cache buffer chains 的等待，这句话在这里不确切，只是这样可能会缩短sql执行时间，减少热点的竞争机会,但并不是说减少 cache buffer chains 的访问次数

·                                 # 回复：深度分析数据库的热点块问题

prada_gu
Posted @ 2004-07-08 3:31 PM
呵呵,BITI就是对internal肯花时间研究呀, :)

·                                 # 回复：深度分析数据库的热点块问题

LI2
Posted @ 2004-07-09 9:52 PM
下午一不小心把分析数据全删了,结果就出来热点块问题.原先用是choose 方案,我想应该是使用rule 方案之后数据库胡乱用索引造成的.后来重新分析了相关表,故障就消失了.
看来胡乱管理数据库是不行了,还要好好学习.

·                                 # 回复：深度分析数据库的热点块问题

LoveWinter
Posted @ 2004-07-13 9:31 PM
有几个问题:
1. 10G的数据库，检测过程中发现'cache buffers chains' 很多, 用文中的SQL
查出来一些热点表和索引，但是它们所在
的表空间都是ASSM管理的，是不是不能
再人为的调整freelist了?

2. 9i/10G 的数据库，已经启用了undo tablespace,但是undo header的等待
依然比较多? 怎样调整?

谢谢!

·                                 # 回复：深度分析数据库的热点块问题

biti_rainy
Posted @ 2004-07-15 9:52 PM
你的这个问题，恐怕只能从业务和sql的角度来考虑了，数据库本身难以有什么调整的

·                                 # 回复：深度分析数据库的热点块问题

Yong Huang
Posted @ 2004-07-21 2:55 AM
Excellent article. One suggestion: change order by misses to order by sleeps when you select from x$bh. The statement "gets表示总共有这么多次请求，misses表示请求失败的次数" is not accurate. Gets does not include Spin Gets. Besides, Steve Adams' book p.23 says if the process sleeps and wakes up later (and/or does this multiple times), the numbers gets, misses and spin gets will NOT be incremented any more. That's probably the reason people use sleeps to indirectly measure the contention to acquire latches.

·                                 # 回复：深度分析数据库的热点块问题

biti_rainy
Posted @ 2004-07-21 9:25 AM
ok.谢谢 yong huang 的提醒，我做过修正

·                                 # 回复：深度分析数据库的热点块问题

Yong Huang
Posted @ 2004-07-21 10:10 PM
Correction for my "correction". I said "change order by misses to order by sleeps when you select from x$bh". I should have said "... when you select from v$latch(_children)". I know you spotted this minor error. But sorry for that.

·                                 # 回复：深度分析数据库的热点块问题

biti_rainy
Posted @ 2004-07-22 2:34 AM
其实若你所言，使用 misses 或者 sleeps ,未必存在哪个一定更准确，若sleeps极少（或者说进程总是多次misses而很少sleep），则misses相对准确一些，若sleeps很多，则sleeps相对准确一些。但是一个进程通常 在获取一个latch的过程中sleeps不会太多，这样使得misses总是经常远大于sleeps，除非 _spin_count 非常的小 或者 系统latch竞争严重到sleeps异常的多的情况下，sleeps才更准确一些

·                                 # 回复：深度分析数据库的热点块问题

Yong Huang
Posted @ 2004-08-04 12:02 AM
You have a good point. I'm trying to figure out why most people order by sleeps, instead of gets or misses. What bothers me is the fact that Steve Adams says that after one sleep, none of the numbers except sleeps are incremented. But as you say, if most gets turn out to be successful (i.e. gets lead to obtaining latches), then sleeps are such small numbers that errors (wu4 cha1) become inevitable.

However, I've never seen anybody mention the potentially very useful column wait_time in v$latch(_children), new in 9i. I believe wait_time is a better indicator. Although I doubt it, I don't know if it suffers the same limitation as most other columns, i.e. the number freezes after one sleep.