Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › 关于cache buffer chain 、hash bucket、hash chain的讨 ...

89 积分	0 好友	0 主题

发消息

关于cache buffer chain 、hash bucket、hash chain的讨论

1^#

发表于 2012-5-9 09:02:33 | 查看: 13474| 回复: 22

关于刘大一篇文章中“得到buffer handle的过程中首先要抢占cache buffer handles栓” 找到buffer了不是直接pin住吗，怎么还有一个栓哦。。其它地方都没看到过关于这个过程的资料，刘大能不能详细说说~

==================================================================================

comment by maclean

这个帖子由于原帖没有表达清楚，现改为对 cache buffer chain 、hash bucket、hash chain的讨论

收藏0 回复只看该作者道具举报

23^#

发表于 2013-12-7 10:34:48

虽然看不懂，但是感觉这个好精彩的扫盲贴，改天头脑清醒的时候学习下，O(∩_∩)O哈哈~

回复只看该作者道具举报

Liu Maclean(刘相兵

22^#

发表于 2013-12-6 21:05:29

fibonacci 发表于 2013-12-6 16:39
hash bucket的结构是怎么样的，他里面是不是放的就是一个一个bufer header 和 class 经过hash运算后的值？ ...

最好搞过C和数据结构，否则听了还是玄虚

回复只看该作者道具举报

21^#

发表于 2013-12-6 16:39:14

hash bucket的结构是怎么样的，他里面是不是放的就是一个一个bufer header 和 class 经过hash运算后的值？

回复只看该作者道具举报

Maclean Liu(刘相兵

20^#

发表于 2012-5-14 20:24:09

cache buffer hash chains 数量越少则单个 cbc latch管理的 chains 越少，最少的情况下一个 cbc latch 管理一条 cbc chains

SQL> select  * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0    Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
  2 FROM SYS.x$ksppi x, SYS.x$ksppcv y
  3 WHERE x.inst_id = USERENV ('Instance')
  4 AND y.inst_id = USERENV ('Instance')
  5 AND x.indx = y.indx
  6  AND x.ksppinm='_db_block_hash_buckets';


  NAME
--------------------------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
DESCRIB
--------------------------------------------------------------------------------
_db_block_hash_buckets
1048576
Number of database block hash buckets

SQL> select count(distinct(HLADDR)) from x$Bh;

COUNT(DISTINCT(HLADDR))
-----------------------
               4539

SQL> alter system set "_db_block_hash_buckets"=1024 scope=spfile;

System altered.

SQL> startup force;
ORACLE instance started.

Total System Global Area  851443712 bytes
Fixed Size                2100040 bytes
Variable Size          738198712 bytes
Database Buffers       104857600 bytes
Redo Buffers             6287360 bytes
Database mounted.
Database opened.
SQL> show parameter hash

NAME                               TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
_db_block_hash_buckets             integer
1024




SQL> select count(distinct(HLADDR)) from x$Bh;

COUNT(DISTINCT(HLADDR))
-----------------------
                  998

回复只看该作者道具举报

19^#

发表于 2012-5-14 17:59:27

这两天上网查了下资料，select count(*) ,HLADDR from x$bh group by HLADDR 中的hladdr应该是cache buffer chain latch 的address，在刘大的实验中"_db_block_hash_buckets"=256 ，此时一个cbc chain latch 管理一个 bucket。不知道这样的理解是否准确？？

回复只看该作者道具举报

18^#

发表于 2012-5-10 22:22:53

仔细看了下，chche buffer chain与hash chain应该是指同一个东西。
再请教一下，在5#中
（1）select count(*) ,HLADDR from x$bh group by HLADDR;
中的hladdr指的是谁的地址？与dump buffers的trace文件中的哪个地址相对应？
（2）为何chain 165,chain 67,chain 192,chain 94 中都只有一个bh?而x$bh的查询结果中都有几十个bh？

回复只看该作者道具举报

Maclean Liu(刘相兵

17^#

发表于 2012-5-10 22:19:59

cache buffer chain 简写为cbc 也就叫做 cache buffer hash chain

回复只看该作者道具举报

16^#

发表于 2012-5-10 22:04:40

maclean,看了半天还是没明白cache buffer chain与 hash chain有什么区别。
到底有几条chain？一条还是两条？是不是cache buffer chain、 hash chain是一个东西？？

回复只看该作者道具举报

15^#

发表于 2012-5-10 09:54:29

回复 10# 的帖子

8#确定是这样？应该是一个bucket就是一个chain吧？然后一个latch可以管理多个chain

回复只看该作者道具举报

14^#

发表于 2012-5-10 09:10:24

真不错..学习了...

回复只看该作者道具举报

Maclean Liu(刘相兵

13^#

发表于 2012-5-9 23:00:26

MORE ODM FINDING:

Hash Buckets and Chains
Any access to the hash chain is protected by the corresponding cache buffers chains latch. The hash chain itself is updated via a generic link list mechanism. Although each hash bucket has a cache buffers chains latch to protect concurrent access to the chain, it is not necessarily a one-to-one correspondence because multiple buckets may share a latch. The default number of these latches is calculated as: Initial = buffers / 128. This is adjusted upward if it is too low.

Default number of hash buckets: (DB_BLOCK_BUFFERS x 2)
The parameter _DB_BLOCK_HASH_BUCKETS can be used to overwrite the default.
Each hash bucket contains a chain of buffer headers for a set of <RDBA, class> pairs.
Each hash bucket has a cache buffers chains latch to protect concurrent access to the chain.

回复只看该作者道具举报

Maclean Liu(刘相兵

12^#

发表于 2012-5-9 22:54:03

补充一下：

说2个块不在同一个 hash chains 就不会造成cbc latch争用是不准确的，  上面的说明中这样解释是为了容易理解。  实际一个cache buffer chains latch 会管理多个 cache buffer chain ，所以若 2个 data buffer header 恰好在同一个 cbc latch 管理的 hash chains上的话还是有可能造成 contention 。  但是 hash fun 会尽可能让  相邻块(neighborhood block) 分布在不同 latch 管理的 hash chains上。

SQL> select count(*) from test_buffer_bucket;

  COUNT(*)
----------
   75315


SQL> select count(*) from test_buffer_bucket;

  COUNT(*)
----------
   75315

select DBABLK,HLADDR from x$bh where OBJ=81261 order by DBABLK    ;

HLADDR  RAW(4) Hash Chain Latch Address
.................................................
DBABLK HLADDR
---------- ----------------
233122 00000000973A1F90
233123 000000009739CDB8
233124 00000000973A5308
233125 00000000973A0058
233126 000000009739ADA8
233127 00000000973A32F8
233128 000000009739E120
233129 00000000973A6670
233392 00000000973A02E0
234798 000000009739F710
237424 000000009739EA68

DBABLK HLADDR
---------- ----------------
237425 00000000973997B8
237426 00000000973A1D08
237427 000000009739CA58
237428 00000000973A4FA8
237429 000000009739FDD0
237430 000000009739AB20
237431 00000000973A3070

回复只看该作者道具举报

Maclean Liu(刘相兵

11^#

发表于 2012-5-9 22:35:54

回复 10# 的帖子

以下演示用以证明 hash chains 和 hash bucket 是一对一的关系

SQL> show parameter hash

NAME                               TYPE       VALUE
------------------------------------ ----------- ------------------------------
_db_block_hash_buckets             integer    256

参数指定 256个 hash buckets

SQL> oradebug setmypid;
Statement processed.
SQL> oradebug dump buffers 4;
Statement processed.
SQL> oradebug tracefile_name;
/s01/orabase/diag/rdbms/g11r23/G11R23/trace/G11R23_ora_29099.trc

CHAIN: 0 LOC: 0x97399880 HEAD: [NULL]

CHAIN: 242 LOC: 0x973a64b0 HEAD: [NULL]
CHAIN: 243 LOC: 0x973a6588 HEAD: [NULL]
CHAIN: 244 LOC: 0x973a6660 HEAD: [NULL]
CHAIN: 245 LOC: 0x973a6738 HEAD: [NULL]
CHAIN: 246 LOC: 0x973a6810 HEAD: [NULL]
CHAIN: 247 LOC: 0x973a68e8 HEAD: [NULL]
CHAIN: 248 LOC: 0x973a69c0 HEAD: [NULL]
CHAIN: 249 LOC: 0x973a6a98 HEAD: [NULL]
CHAIN: 250 LOC: 0x973a6b70 HEAD: [NULL]
CHAIN: 251 LOC: 0x973a6c48 HEAD: [NULL]
CHAIN: 252 LOC: 0x973a6d20 HEAD: [NULL]
CHAIN: 253 LOC: 0x973a6df8 HEAD: [NULL]
CHAIN: 254 LOC: 0x973a6ed0 HEAD: [NULL]
CHAIN: 255 LOC: 0x973a6fa8 HEAD: [NULL]

从buffer dump中可以明确看到 chain 0 - chian 255  , 256 个 hash chains

回复只看该作者道具举报

10^#

发表于 2012-5-9 22:17:56

--------------------------------------------------------------------------------例如 data file 4 上的 block 18 和 block 19是应用经常要访问的热快，经过HASH算法之后这2个块就不会落在同一个HASH Buckets中，这样避免了对同一条hash chain的争用
--------------------------------------------------------------------------------
一个hash chain可以同时对应多个hash buckets，两个data block即使分别在不同的hash buckets，还是会可能产生争用。

回复只看该作者道具举报

Maclean Liu(刘相兵

9^#

发表于 2012-5-9 18:07:15

回复 8# 的帖子

这个帖子由于原帖没有表达清楚，现改为对 cache buffer chain 、hash bucket、hash chain的讨论

如果对 buffer handle有疑问请另外开一个帖子

回复只看该作者道具举报

8^#

发表于 2012-5-9 17:52:14

刚才的回帖被删了还是咋回事啊~~再发一次~~

刘大误会我的意思了，我是想问关于buffer header 上的栓cache buffer handles这方面的资料，因为从来没有地方介绍过这个栓，在您的文章《latch free:cache buffer handles造成的SQL性能问题》里：
当会话需要pin住buffer header时它首先要获去buffer handle，得到buffer handle的过程中首先要抢占cache buffer handles栓，为了避免对于cache buffer handles栓的过度争用，每个会话被允许cache一小撮buffer handles,也叫保留集(reserved set)。该保留集的上限由隐式参数_db_handles_cached(默认为5)所控制，在此基础上会话在执行不是十分复杂的SQL时不必反复申请栓。

说到了这个栓，所以想请教一下相关资料~

另外我发现这个栓在latch children里没有子栓，它是如何工作的呢~

回复只看该作者道具举报

7^#

发表于 2012-5-9 17:11:49

刘大误会了，我想问的是关于看了您的一篇博文后不明白的地方，
文章名字《latch free:cache buffer handles造成的SQL性能问题》
关于这个栓：
当会话需要pin住buffer header时它首先要获去buffer handle，得到buffer handle的过程中首先要抢占cache buffer handles栓，为了避免对于cache buffer handles栓的过度争用，每个会话被允许cache一小撮buffer handles,也叫保留集(reserved set)。该保留集的上限由隐式参数_db_handles_cached(默认为5)所控制，在此基础上会话在执行不是十分复杂的SQL时不必反复申请栓。

这个栓我在其它地方都没有看到过，从v$latch_children里查看这个栓也是没有子栓的，请教一下关于这个栓的资料~

回复只看该作者道具举报

6^#

发表于 2012-5-9 17:07:35

好谢谢啊学习了

回复只看该作者道具举报

Maclean Liu(刘相兵

5^#

发表于 2012-5-9 16:59:08

回复 3# 的帖子

我们修改隐藏参数 _db_block_hash_buckets ，将hash buckets 的数量减少到最少(256)；
这会导致大量的 BH 将不得不存放在少数的hash buckets中，再观察相邻块的表现；

复制代码

以上可以看到在hash bucket 非常有限的情况下，一个bucket 中会存放比平时多得多的 BH buffer header，

block#  162816  在CHAIN: 165
block#  162817  在CHAIN: 67
block#  162944  在CHAIN: 192
block#  162945  在CHAIN: 94
block#  237568  CHAIN: 97
block#  237569  CHAIN: 255
block#  237570  CHAIN: 157
block#  237571  CHAIN: 59

但是因为 HASH algorithm  对于 Block的RDBA+CLASS 的散列作用，相邻的数据块(neighborhood block)会尽可能分在不同的bucket内。

可以看一下同一个 table object的 buffer header在同一个 hash bucket中的情况，可以看到这些同一个hash bucket 中的BH 总是在物理上那样疏远：

CHAIN 245 :(4/233129)  (4/203462)  (4/185178)
CHAIN 247:  (4/223233)  (4/196739) (4/163200)

CHAIN: 245 LOC: 0x973a6738 HEAD: [0x7b7ea028,0x817f2fd8]
BH (0x7b7e9f78) file#: 4 rdba: 0x01038ea9 (4/233129) class: 1 ba: 0x7b5e6000
set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 77,22
dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
hash: [0x7bbddd68,0x973a6738] lru: [0x7b7ea190,0x7b7e9e00]
lru-flags: debug_dump
ckptq: [NULL] fileq: [NULL] objq: [0x7b7ea1b8,0x7b7e9f58] objaq: [0x7b7ea1c8,0x7b7e9f68]
st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 0
flags: only_sequential_access prefetched_block
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
BH (0x7bbddcb8) file#: 4 rdba: 0x01031ac6 (4/203462) class: 1 ba: 0x7b89e000
set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 78,22
dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
hash: [0x7bbdfd78,0x7b7ea028] lru: [0x7bbdded0,0x7bbddc70]
lru-flags: debug_dump
ckptq: [NULL] fileq: [NULL] objq: [0x7bbddef8,0x7bbddc98] objaq: [0x7bbddf08,0x7bbddca8]
st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 0
flags: only_sequential_access prefetched_block
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
BH (0x7bbdfcc8) file#: 4 rdba: 0x0102d35a (4/185178) class: 1 ba: 0x7b8d4000
set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 78,22
dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
hash: [0x7c3e0238,0x7bbddd68] lru: [0x7bbdfc80,0x7bbe03a0]
lru-flags: debug_dump moved_to_tail
ckptq: [NULL] fileq: [NULL] objq: [0x7bbdff08,0x7bbdfca8] objaq: [0x7bbdff18,0x7bbdfcb8]
st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 0
flags: only_sequential_access
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

复制代码

回复只看该作者道具举报

4^#

发表于 2012-5-9 16:00:40

为什么很多时候，cache buffer chain是BUG

有些时候这个等待是由于SQL的执行计划改变而导致的热块争用，
但有些时候这个是BUG，我一般去做的是对比执行计划，或者抓TOP SQL查看执行计划，
但如果是BUG，一般需要怎么确认？

回复只看该作者道具举报

3^#

发表于 2012-5-9 16:00:33

例如 data file 4 上的 block 18 和 block 19是应用经常要访问的热快，经过HASH算法之后这2个块就不会落在同一个HASH Buckets中，这样避免了对同一条hash chain的争用。
这个说法不是很对吧一个hash bucket管理一段区域内的hash value,只要落在这个hash value范围内的buffer,都会挂在该hash chain上，由同一个cache buffer chain latch管理

回复只看该作者道具举报

Maclean Liu(刘相兵

2^#

发表于 2012-5-9 15:51:44

你说的是 cache buffer chain 的相关latch ，首先需要搞明白为什么要有 cache buffer chain(hash chain) 和 cache buffer bucket (hash bucket)

对于Buffer cache管理而言 oracle所需要解决的问题包括几个：

1.  如何快速定位一个data buffer header，因为 Buffer cache中的 data buffer header 是非常多的，若为了找一个data buffer header 而去对所有的 buffer header都扫描一遍，那将是非常低效的。

举个例子来说服务进程要有读取 datafile 5 block 10的需求，这个时候难道服务进程一开始就知道 data file 5 的 block 10在是不是在 Buffer cache中，  在Buffer cache中的哪里？　这些信息　Server process都是不知道的。

如果 data buffer header被使用普通的双向链表组织，那么如果要确定一个 data buffer是否在 Buffer Cache中，那么需要把这个双向链表上所有的buffer header都查看一遍，这是十分低效的。

2.  对 data buffer header 高效的并发管理，避免出现争用。

为了实现高效管理 data buffer header的目的， oracle 使用 hash buckets的结构来组织 data buffer header，通过对 data buffer header 的不同 rdba 和 class 做HASH 算法来实现对 buffer header的高效管理，  通俗来说 HASH做的就是一件事  ，  例如 data file 4 上的 block 18 和 block 19是应用经常要访问的热快，经过HASH算法之后这2个块就不会落在同一个HASH Buckets中，这样避免了对同一条hash chain的争用。

oracle又通过  hash chains( cache buffer chain) 将一个bucket 上的buffer header串起来，  注意同一个data block在oracle中可能会有多个buffer ，分别对应为一个 current block 和可能的多个 cr block，这些block都同一条 cache buffer chains上。

为了实现对cache buffer chains的并发控制需要用到 latch来管理，所以会有 cache buffer chains latch。

CBC 的latch管理是 Buffer cache Internal的主要部分，值得研究但是并非一段文字所能全部描述。

你也可以参考下面这个图示：

回复只看该作者道具举报

|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-21 12:50 , Processed in 0.062900 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部

TEL/電話+86 13764045638

Email service@parnassusdata.com

QQ 47079569