关于cache buffer chain 、hash bucket、hash chain的讨论
关于刘大一篇文章中“得到buffer handle的过程中首先要抢占cache buffer handles栓” 找到buffer了不是直接pin住吗，怎么还有一个栓哦。。其它地方都没看到过关于这个过程的资料，刘大能不能详细说说~==================================================================================
comment by maclean
这个帖子由于 原帖没有表达清楚，现改为对 cache buffer chain 、hash bucket、hash chain的讨论 你说的 是 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的主要部分，值得研究 但是并非 一段文字所能全部描述。
你也可以参考下面 这个图示：
例如 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管理
为什么很多时候，cache buffer chain是BUG
有些时候这个等待是由于SQL的执行计划改变而导致的热块争用，但有些时候这个是BUG，我一般去做的是对比执行计划，或者抓TOP SQL查看执行计划，
但如果是BUG，一般需要怎么确认？
回复 3# 的帖子
我们修改 隐藏参数 _db_block_hash_buckets ， 将hash buckets 的数量减少到 最少(256)；这会导致大量的 BH 将不得不存放在少数的hash buckets中， 再观察相邻块的 表现；SQL> alter system set "_db_block_hash_buckets"=256 scope=spfile;
System altered.
SQL> startup force;
ORACLE instance started.
Total System Global Area 939495424 bytes
Fixed Size 2233960 bytes
Variable Size 708839832 bytes
Database Buffers 222298112 bytes
Redo Buffers 6123520 bytes
Database mounted.
Database opened.
SQL> show parameter hash
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_db_block_hash_buckets integer 256
hash_area_size integer 131072
SQL>
SQL>
SQL> create table test_buffer_bucket tablespace users pctfree 99 as select * from dba_objects ;
Table created.
SQL> select object_id,data_object_id from dba_objects where object_name='TEST_BUFFER_BUCKET';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
81261 81261
SQL> select count(*) from test_buffer_bucket;
COUNT(*)
----------
75315
SQL> select count(*) from test_buffer_bucket;
COUNT(*)
----------
75315
SQL> select file#,block#,class# from v$bh where OBJD=81261 order by block#
2 ;
FILE# BLOCK# CLASS#
---------- ---------- ----------
4 162816 8
4 162817 8
4 162944 8
4 162945 8
4 163072 8
4 163073 8
4 163200 8
4 163201 8
4 163328 8
4 163329 8
4 163456 8
.............
FILE# BLOCK# CLASS#
---------- ---------- ----------
4 237489 1
4 237568 8
4 237569 8
4 237570 8
4 237571 8
4 238254 1
4 238592 8
4 238593 8
4 238594 8
4 238595 8
593 rows selected.
SQL> select count(*) ,HLADDR from x$bh group by HLADDR;
COUNT(*) HLADDR
---------- ----------------
58 00000000973997B8
44 0000000097399890
52 0000000097399968
47 0000000097399BF0
52 0000000097399CC8
47 0000000097399E78
45 000000009739A028
46 000000009739A100
45 000000009739A460
49 000000009739A538
44 000000009739A610
COUNT(*) HLADDR
---------- ----------------
42 000000009739A7C0
53 000000009739A898
33 000000009739A970
49 000000009739AA48
53 000000009739ADA8
51 000000009739AE80
54 000000009739B1E0
41 000000009739B2B8
50 000000009739B468
44 000000009739B6F0
42 000000009739B8A0
COUNT(*) HLADDR
---------- ----------------
46 000000009739BA50
39 000000009739BCD8
51 000000009739C038
49 000000009739C110
46 000000009739C2C0
53 000000009739C620
43 000000009739C6F8
44 000000009739CE90
41 000000009739CF68
46 000000009739D118
47 000000009739D2C8
COUNT(*) HLADDR
---------- ----------------
46 000000009739D3A0
51 000000009739D550
37 000000009739D7D8
46 000000009739D8B0
36 000000009739DA60
44 000000009739DB38
36 000000009739DC10
41 000000009739DCE8
51 000000009739DDC0
52 000000009739E048
45 000000009739E2D0
COUNT(*) HLADDR
---------- ----------------
57 000000009739E480
45 000000009739E558
44 000000009739E630
41 000000009739E708
50 000000009739E990
43 000000009739EC18
44 000000009739ECF0
56 000000009739EEA0
39 000000009739EF78
52 000000009739F200
40 000000009739F2D8
COUNT(*) HLADDR
---------- ----------------
35 000000009739F560
50 000000009739F638
55 000000009739F7E8
47 000000009739F8C0
39 000000009739F998
32 000000009739FC20
58 000000009739FCF8
45 000000009739FEA8
43 00000000973A0130
53 00000000973A0490
48 00000000973A0568
COUNT(*) HLADDR
---------- ----------------
40 00000000973A0640
53 00000000973A0718
41 00000000973A07F0
40 00000000973A08C8
43 00000000973A0A78
49 00000000973A0B50
45 00000000973A0DD8
54 00000000973A0EB0
42 00000000973A1060
43 00000000973A1138
50 00000000973A1210
COUNT(*) HLADDR
---------- ----------------
54 00000000973A12E8
45 00000000973A13C0
44 00000000973A1498
49 00000000973A1648
52 00000000973A1720
45 00000000973A17F8
52 00000000973A18D0
35 00000000973A19A8
38 00000000973A1C30
52 00000000973A1EB8
39 00000000973A2068
COUNT(*) HLADDR
---------- ----------------
48 00000000973A23C8
51 00000000973A24A0
48 00000000973A2578
42 00000000973A2728
42 00000000973A2800
41 00000000973A28D8
41 00000000973A2A88
52 00000000973A2B60
42 00000000973A2C38
41 00000000973A2EC0
48 00000000973A2F98
COUNT(*) HLADDR
---------- ----------------
52 00000000973A32F8
38 00000000973A34A8
48 00000000973A3580
42 00000000973A38E0
49 00000000973A3B68
52 00000000973A3D18
40 00000000973A3DF0
40 00000000973A3FA0
52 00000000973A4300
44 00000000973A43D8
44 00000000973A44B0
COUNT(*) HLADDR
---------- ----------------
51 00000000973A49C0
51 00000000973A4A98
49 00000000973A4B70
30 00000000973A4C48
44 00000000973A4D20
50 00000000973A4DF8
56 00000000973A4FA8
49 00000000973A5230
45 00000000973A5308
43 00000000973A53E0
39 00000000973A5590
COUNT(*) HLADDR
---------- ----------------
54 00000000973A5668
47 00000000973A5740
39 00000000973A58F0
51 00000000973A59C8
35 00000000973A5D28
41 00000000973A6238
46 00000000973A6310
41 00000000973A64C0
48 00000000973A6820
38 00000000973A68F8
47 00000000973A6AA8
COUNT(*) HLADDR
---------- ----------------
59 00000000973A6D30
42 0000000097399A40
42 0000000097399B18
51 0000000097399DA0
46 0000000097399F50
54 000000009739A1D8
42 000000009739A2B0
38 000000009739A388
47 000000009739A6E8
53 000000009739AB20
51 000000009739ABF8
COUNT(*) HLADDR
---------- ----------------
42 000000009739ACD0
51 000000009739AF58
50 000000009739B030
39 000000009739B108
41 000000009739B390
42 000000009739B540
46 000000009739B618
53 000000009739B7C8
55 000000009739B978
45 000000009739BB28
45 000000009739BC00
COUNT(*) HLADDR
---------- ----------------
43 000000009739BDB0
46 000000009739BE88
49 000000009739BF60
44 000000009739C1E8
53 000000009739C398
39 000000009739C470
50 000000009739C548
49 000000009739C7D0
40 000000009739C8A8
51 000000009739C980
61 000000009739CA58
COUNT(*) HLADDR
---------- ----------------
55 000000009739CB30
39 000000009739CC08
52 000000009739CCE0
32 000000009739CDB8
43 000000009739D040
47 000000009739D1F0
53 000000009739D478
40 000000009739D628
44 000000009739D700
44 000000009739D988
60 000000009739DE98
COUNT(*) HLADDR
---------- ----------------
37 000000009739DF70
35 000000009739E120
42 000000009739E1F8
41 000000009739E3A8
56 000000009739E7E0
42 000000009739E8B8
57 000000009739EA68
36 000000009739EB40
38 000000009739EDC8
46 000000009739F050
42 000000009739F128
COUNT(*) HLADDR
---------- ----------------
56 000000009739F3B0
42 000000009739F488
42 000000009739F710
45 000000009739FA70
50 000000009739FB48
58 000000009739FDD0
47 000000009739FF80
53 00000000973A0058
44 00000000973A0208
49 00000000973A02E0
44 00000000973A03B8
COUNT(*) HLADDR
---------- ----------------
46 00000000973A09A0
46 00000000973A0C28
56 00000000973A0D00
36 00000000973A0F88
43 00000000973A1570
53 00000000973A1A80
45 00000000973A1B58
58 00000000973A1D08
43 00000000973A1DE0
45 00000000973A1F90
40 00000000973A2140
COUNT(*) HLADDR
---------- ----------------
54 00000000973A2218
39 00000000973A22F0
54 00000000973A2650
50 00000000973A29B0
46 00000000973A2D10
46 00000000973A2DE8
56 00000000973A3070
50 00000000973A3148
41 00000000973A3220
43 00000000973A33D0
40 00000000973A3658
COUNT(*) HLADDR
---------- ----------------
45 00000000973A3730
49 00000000973A3808
51 00000000973A39B8
49 00000000973A3A90
41 00000000973A3C40
56 00000000973A3EC8
43 00000000973A4078
46 00000000973A4150
40 00000000973A4228
47 00000000973A4588
57 00000000973A4660
COUNT(*) HLADDR
---------- ----------------
39 00000000973A4738
39 00000000973A4810
50 00000000973A48E8
43 00000000973A4ED0
61 00000000973A5080
36 00000000973A5158
50 00000000973A54B8
49 00000000973A5818
35 00000000973A5AA0
39 00000000973A5B78
45 00000000973A5C50
COUNT(*) HLADDR
---------- ----------------
48 00000000973A5E00
44 00000000973A5ED8
42 00000000973A5FB0
42 00000000973A6088
53 00000000973A6160
54 00000000973A63E8
47 00000000973A6598
51 00000000973A6670
36 00000000973A6748
51 00000000973A69D0
53 00000000973A6B80
COUNT(*) HLADDR
---------- ----------------
29 00000000973A6C58
41 00000000973A6E08
47 00000000973A6EE0
256 rows selected.
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_27444.trc
CHAIN: 165 LOC: 0x973a23b8 HEAD:
BH (0x7bfeedd8) file#: 4 rdba: 0x01027c00 (4/162816) class: 8 ba: 0x7be6a000
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: lru:
lru-flags: debug_dump
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
flags: block_written_once redo_since_read
LRBA: LSCN: HSCN: HSUB:
CHAIN: 67 LOC: 0x9739d108 HEAD:
BH (0x7bfd8f88) file#: 4 rdba: 0x01027c01 (4/162817) class: 8 ba: 0x7bc1c000
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: lru:
lru-flags: debug_dump
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
flags: block_written_once redo_since_read
LRBA: LSCN: HSCN: HSUB:
CHAIN: 192 LOC: 0x973a3a80 HEAD:
BH (0x7e7f19c8) file#: 4 rdba: 0x01027c80 (4/162944) class: 8 ba: 0x7e6b4000
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: lru:
lru-flags: debug_dump
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
flags: block_written_once redo_since_read
LRBA: LSCN: HSCN: HSUB:
CHAIN: 94 LOC: 0x9739e7d0 HEAD:
BH (0x7bfda288) file#: 4 rdba: 0x01027c81 (4/162945) class: 8 ba: 0x7bc3c000
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: lru:
lru-flags: debug_dump
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
flags: block_written_once redo_since_read
LRBA: LSCN: HSCN: HSUB:
以上可以看到 在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:
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: lru:
lru-flags: debug_dump
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 0
flags: only_sequential_access prefetched_block
LRBA: LSCN: HSCN: HSUB:
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: lru:
lru-flags: debug_dump
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 0
flags: only_sequential_access prefetched_block
LRBA: LSCN: HSCN: HSUB:
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: lru:
lru-flags: debug_dump moved_to_tail
ckptq: fileq: objq: objaq:
st: XCURRENT md: NULL fpin: 'kdswh01: kdstgr' tch: 0
flags: only_sequential_access
LRBA: LSCN: HSCN: HSUB:
好 谢谢啊 学习了 刘大误会了，我想问的是关于看了您的一篇博文后不明白的地方，
文章名字《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里查看这个栓也是没有子栓的，请教一下关于这个栓的资料~ 刚才的回帖被删了还是咋回事啊~~再发一次~~
刘大误会我的意思了，我是想问关于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里没有子栓，它是如何工作的呢~
回复 8# 的帖子
这个帖子由于 原帖没有表达清楚，现改为对 cache buffer chain 、hash bucket、hash chain的讨论如果对 buffer handle有疑问 请另外开一个帖子 --------------------------------------------------------------------------------例如 data file 4 上的 block 18 和 block 19是 应用经常要访问的热快， 经过HASH算法之后 这2个块 就不会落在同一个HASH Buckets中，这样避免了对 同一条hash chain的争用
--------------------------------------------------------------------------------
一个hash chain可以同时对应多个hash buckets，两个data block即使分别在不同的hash buckets，还是会可能产生争用。
回复 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:
CHAIN: 242 LOC: 0x973a64b0 HEAD:
CHAIN: 243 LOC: 0x973a6588 HEAD:
CHAIN: 244 LOC: 0x973a6660 HEAD:
CHAIN: 245 LOC: 0x973a6738 HEAD:
CHAIN: 246 LOC: 0x973a6810 HEAD:
CHAIN: 247 LOC: 0x973a68e8 HEAD:
CHAIN: 248 LOC: 0x973a69c0 HEAD:
CHAIN: 249 LOC: 0x973a6a98 HEAD:
CHAIN: 250 LOC: 0x973a6b70 HEAD:
CHAIN: 251 LOC: 0x973a6c48 HEAD:
CHAIN: 252 LOC: 0x973a6d20 HEAD:
CHAIN: 253 LOC: 0x973a6df8 HEAD:
CHAIN: 254 LOC: 0x973a6ed0 HEAD:
CHAIN: 255 LOC: 0x973a6fa8 HEAD:
从buffer dump中可以明确 看到 chain 0 - chian 255 , 256 个 hash chains 补充一下：
说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 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. 真不错..学习了...
回复 10# 的帖子
8#确定是这样？应该是一个bucket就是一个chain吧？然后一个latch可以管理多个chain maclean,看了半天还是没明白cache buffer chain与 hash chain有什么区别。到底有几条chain？一条还是两条？是不是cache buffer chain、 hash chain是一个东西？？ cache buffer chain 简写为cbc 也就叫做 cache buffer hash chain 仔细看了下，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？ 这两天上网查了下资料，select count(*) ,HLADDR from x$bh group by HLADDR 中的hladdr应该是cache buffer chain latch 的address，在刘大的实验中"_db_block_hash_buckets"=256 ，此时一个cbc chain latch 管理一个 bucket。不知道这样的理解是否准确？？ 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 hash bucket的结构是怎么样的，他里面是不是放的就是一个一个bufer header 和 class 经过hash运算后的值？ fibonacci 发表于 2013-12-6 16:39 static/image/common/back.gif
hash bucket的结构是怎么样的，他里面是不是放的就是一个一个bufer header 和 class 经过hash运算后的值？ ...
最好搞过C和数据结构，否则听了还是玄虚 虽然看不懂，但是感觉这个好精彩的扫盲贴，改天头脑清醒的时候学习下，O(∩_∩)O哈哈~
页:
[1]