Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

89

积分

0

好友

0

主题
1#
发表于 2012-5-9 09:02:33 | 查看: 13473| 回复: 22
关于刘大一篇文章中“得到buffer handle的过程中首先要抢占cache buffer handles栓”    找到buffer了不是直接pin住吗,怎么还有一个栓哦。。其它地方都没看到过关于这个过程的资料,刘大能不能详细说说~








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

comment by  maclean


这个帖子由于 原帖没有表达清楚,现改为对 cache buffer chain 、hash bucket、hash chain的讨论
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的主要部分,值得研究 但是并非 一段文字所能全部描述。

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

cbc_latch.png

回复 只看该作者 道具 举报

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管理

回复 只看该作者 道具 举报

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

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

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

回复 只看该作者 道具 举报

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

回复 3# 的帖子

我们修改 隐藏参数 _db_block_hash_buckets , 将hash buckets 的数量减少到 最少(256);
这会导致大量的 BH 将不得不存放在少数的hash buckets中, 再观察相邻块的 表现;
  1. SQL> alter system set "_db_block_hash_buckets"=256 scope=spfile;

  2. System altered.

  3. SQL> startup force;
  4. ORACLE instance started.

  5. Total System Global Area  939495424 bytes
  6. Fixed Size                  2233960 bytes
  7. Variable Size             708839832 bytes
  8. Database Buffers          222298112 bytes
  9. Redo Buffers                6123520 bytes
  10. Database mounted.
  11. Database opened.


  12. SQL> show parameter hash

  13. NAME                                 TYPE        VALUE
  14. ------------------------------------ ----------- ------------------------------
  15. _db_block_hash_buckets               integer     256
  16. hash_area_size                       integer     131072


  17. SQL>
  18. SQL>
  19. SQL> create table test_buffer_bucket tablespace users pctfree 99 as select * from dba_objects ;

  20. Table created.


  21. SQL>  select object_id,data_object_id from dba_objects where object_name='TEST_BUFFER_BUCKET';

  22. OBJECT_ID DATA_OBJECT_ID
  23. ---------- --------------
  24.      81261          81261         
  25.          

  26. SQL> select count(*) from test_buffer_bucket;

  27.   COUNT(*)
  28. ----------
  29.      75315

  30. SQL>  select count(*) from test_buffer_bucket;

  31.   COUNT(*)
  32. ----------
  33.      75315
  34.          
  35. SQL>  select file#,block#,class# from v$bh where OBJD=81261 order by block#
  36.   2  ;


  37.      FILE#     BLOCK#     CLASS#
  38. ---------- ---------- ----------
  39.          4     162816          8
  40.          4     162817          8
  41.          4     162944          8
  42.          4     162945          8
  43.          4     163072          8
  44.          4     163073          8
  45.          4     163200          8
  46.          4     163201          8
  47.          4     163328          8
  48.          4     163329          8
  49.          4     163456          8
  50. .............


  51.      FILE#     BLOCK#     CLASS#
  52. ---------- ---------- ----------
  53.          4     237489          1
  54.          4     237568          8
  55.          4     237569          8
  56.          4     237570          8
  57.          4     237571          8
  58.          4     238254          1
  59.          4     238592          8
  60.          4     238593          8
  61.          4     238594          8
  62.          4     238595          8

  63. 593 rows selected.


  64. SQL> select count(*) ,HLADDR from x$bh group by HLADDR;

  65.   COUNT(*) HLADDR
  66. ---------- ----------------
  67.         58 00000000973997B8
  68.         44 0000000097399890
  69.         52 0000000097399968
  70.         47 0000000097399BF0
  71.         52 0000000097399CC8
  72.         47 0000000097399E78
  73.         45 000000009739A028
  74.         46 000000009739A100
  75.         45 000000009739A460
  76.         49 000000009739A538
  77.         44 000000009739A610

  78.   COUNT(*) HLADDR
  79. ---------- ----------------
  80.         42 000000009739A7C0
  81.         53 000000009739A898
  82.         33 000000009739A970
  83.         49 000000009739AA48
  84.         53 000000009739ADA8
  85.         51 000000009739AE80
  86.         54 000000009739B1E0
  87.         41 000000009739B2B8
  88.         50 000000009739B468
  89.         44 000000009739B6F0
  90.         42 000000009739B8A0

  91.   COUNT(*) HLADDR
  92. ---------- ----------------
  93.         46 000000009739BA50
  94.         39 000000009739BCD8
  95.         51 000000009739C038
  96.         49 000000009739C110
  97.         46 000000009739C2C0
  98.         53 000000009739C620
  99.         43 000000009739C6F8
  100.         44 000000009739CE90
  101.         41 000000009739CF68
  102.         46 000000009739D118
  103.         47 000000009739D2C8

  104.   COUNT(*) HLADDR
  105. ---------- ----------------
  106.         46 000000009739D3A0
  107.         51 000000009739D550
  108.         37 000000009739D7D8
  109.         46 000000009739D8B0
  110.         36 000000009739DA60
  111.         44 000000009739DB38
  112.         36 000000009739DC10
  113.         41 000000009739DCE8
  114.         51 000000009739DDC0
  115.         52 000000009739E048
  116.         45 000000009739E2D0

  117.   COUNT(*) HLADDR
  118. ---------- ----------------
  119.         57 000000009739E480
  120.         45 000000009739E558
  121.         44 000000009739E630
  122.         41 000000009739E708
  123.         50 000000009739E990
  124.         43 000000009739EC18
  125.         44 000000009739ECF0
  126.         56 000000009739EEA0
  127.         39 000000009739EF78
  128.         52 000000009739F200
  129.         40 000000009739F2D8

  130.   COUNT(*) HLADDR
  131. ---------- ----------------
  132.         35 000000009739F560
  133.         50 000000009739F638
  134.         55 000000009739F7E8
  135.         47 000000009739F8C0
  136.         39 000000009739F998
  137.         32 000000009739FC20
  138.         58 000000009739FCF8
  139.         45 000000009739FEA8
  140.         43 00000000973A0130
  141.         53 00000000973A0490
  142.         48 00000000973A0568

  143.   COUNT(*) HLADDR
  144. ---------- ----------------
  145.         40 00000000973A0640
  146.         53 00000000973A0718
  147.         41 00000000973A07F0
  148.         40 00000000973A08C8
  149.         43 00000000973A0A78
  150.         49 00000000973A0B50
  151.         45 00000000973A0DD8
  152.         54 00000000973A0EB0
  153.         42 00000000973A1060
  154.         43 00000000973A1138
  155.         50 00000000973A1210

  156.   COUNT(*) HLADDR
  157. ---------- ----------------
  158.         54 00000000973A12E8
  159.         45 00000000973A13C0
  160.         44 00000000973A1498
  161.         49 00000000973A1648
  162.         52 00000000973A1720
  163.         45 00000000973A17F8
  164.         52 00000000973A18D0
  165.         35 00000000973A19A8
  166.         38 00000000973A1C30
  167.         52 00000000973A1EB8
  168.         39 00000000973A2068

  169.   COUNT(*) HLADDR
  170. ---------- ----------------
  171.         48 00000000973A23C8
  172.         51 00000000973A24A0
  173.         48 00000000973A2578
  174.         42 00000000973A2728
  175.         42 00000000973A2800
  176.         41 00000000973A28D8
  177.         41 00000000973A2A88
  178.         52 00000000973A2B60
  179.         42 00000000973A2C38
  180.         41 00000000973A2EC0
  181.         48 00000000973A2F98

  182.   COUNT(*) HLADDR
  183. ---------- ----------------
  184.         52 00000000973A32F8
  185.         38 00000000973A34A8
  186.         48 00000000973A3580
  187.         42 00000000973A38E0
  188.         49 00000000973A3B68
  189.         52 00000000973A3D18
  190.         40 00000000973A3DF0
  191.         40 00000000973A3FA0
  192.         52 00000000973A4300
  193.         44 00000000973A43D8
  194.         44 00000000973A44B0

  195.   COUNT(*) HLADDR
  196. ---------- ----------------
  197.         51 00000000973A49C0
  198.         51 00000000973A4A98
  199.         49 00000000973A4B70
  200.         30 00000000973A4C48
  201.         44 00000000973A4D20
  202.         50 00000000973A4DF8
  203.         56 00000000973A4FA8
  204.         49 00000000973A5230
  205.         45 00000000973A5308
  206.         43 00000000973A53E0
  207.         39 00000000973A5590

  208.   COUNT(*) HLADDR
  209. ---------- ----------------
  210.         54 00000000973A5668
  211.         47 00000000973A5740
  212.         39 00000000973A58F0
  213.         51 00000000973A59C8
  214.         35 00000000973A5D28
  215.         41 00000000973A6238
  216.         46 00000000973A6310
  217.         41 00000000973A64C0
  218.         48 00000000973A6820
  219.         38 00000000973A68F8
  220.         47 00000000973A6AA8

  221.   COUNT(*) HLADDR
  222. ---------- ----------------
  223.         59 00000000973A6D30
  224.         42 0000000097399A40
  225.         42 0000000097399B18
  226.         51 0000000097399DA0
  227.         46 0000000097399F50
  228.         54 000000009739A1D8
  229.         42 000000009739A2B0
  230.         38 000000009739A388
  231.         47 000000009739A6E8
  232.         53 000000009739AB20
  233.         51 000000009739ABF8

  234.   COUNT(*) HLADDR
  235. ---------- ----------------
  236.         42 000000009739ACD0
  237.         51 000000009739AF58
  238.         50 000000009739B030
  239.         39 000000009739B108
  240.         41 000000009739B390
  241.         42 000000009739B540
  242.         46 000000009739B618
  243.         53 000000009739B7C8
  244.         55 000000009739B978
  245.         45 000000009739BB28
  246.         45 000000009739BC00

  247.   COUNT(*) HLADDR
  248. ---------- ----------------
  249.         43 000000009739BDB0
  250.         46 000000009739BE88
  251.         49 000000009739BF60
  252.         44 000000009739C1E8
  253.         53 000000009739C398
  254.         39 000000009739C470
  255.         50 000000009739C548
  256.         49 000000009739C7D0
  257.         40 000000009739C8A8
  258.         51 000000009739C980
  259.         61 000000009739CA58

  260.   COUNT(*) HLADDR
  261. ---------- ----------------
  262.         55 000000009739CB30
  263.         39 000000009739CC08
  264.         52 000000009739CCE0
  265.         32 000000009739CDB8
  266.         43 000000009739D040
  267.         47 000000009739D1F0
  268.         53 000000009739D478
  269.         40 000000009739D628
  270.         44 000000009739D700
  271.         44 000000009739D988
  272.         60 000000009739DE98

  273.   COUNT(*) HLADDR
  274. ---------- ----------------
  275.         37 000000009739DF70
  276.         35 000000009739E120
  277.         42 000000009739E1F8
  278.         41 000000009739E3A8
  279.         56 000000009739E7E0
  280.         42 000000009739E8B8
  281.         57 000000009739EA68
  282.         36 000000009739EB40
  283.         38 000000009739EDC8
  284.         46 000000009739F050
  285.         42 000000009739F128

  286.   COUNT(*) HLADDR
  287. ---------- ----------------
  288.         56 000000009739F3B0
  289.         42 000000009739F488
  290.         42 000000009739F710
  291.         45 000000009739FA70
  292.         50 000000009739FB48
  293.         58 000000009739FDD0
  294.         47 000000009739FF80
  295.         53 00000000973A0058
  296.         44 00000000973A0208
  297.         49 00000000973A02E0
  298.         44 00000000973A03B8

  299.   COUNT(*) HLADDR
  300. ---------- ----------------
  301.         46 00000000973A09A0
  302.         46 00000000973A0C28
  303.         56 00000000973A0D00
  304.         36 00000000973A0F88
  305.         43 00000000973A1570
  306.         53 00000000973A1A80
  307.         45 00000000973A1B58
  308.         58 00000000973A1D08
  309.         43 00000000973A1DE0
  310.         45 00000000973A1F90
  311.         40 00000000973A2140

  312.   COUNT(*) HLADDR
  313. ---------- ----------------
  314.         54 00000000973A2218
  315.         39 00000000973A22F0
  316.         54 00000000973A2650
  317.         50 00000000973A29B0
  318.         46 00000000973A2D10
  319.         46 00000000973A2DE8
  320.         56 00000000973A3070
  321.         50 00000000973A3148
  322.         41 00000000973A3220
  323.         43 00000000973A33D0
  324.         40 00000000973A3658

  325.   COUNT(*) HLADDR
  326. ---------- ----------------
  327.         45 00000000973A3730
  328.         49 00000000973A3808
  329.         51 00000000973A39B8
  330.         49 00000000973A3A90
  331.         41 00000000973A3C40
  332.         56 00000000973A3EC8
  333.         43 00000000973A4078
  334.         46 00000000973A4150
  335.         40 00000000973A4228
  336.         47 00000000973A4588
  337.         57 00000000973A4660

  338.   COUNT(*) HLADDR
  339. ---------- ----------------
  340.         39 00000000973A4738
  341.         39 00000000973A4810
  342.         50 00000000973A48E8
  343.         43 00000000973A4ED0
  344.         61 00000000973A5080
  345.         36 00000000973A5158
  346.         50 00000000973A54B8
  347.         49 00000000973A5818
  348.         35 00000000973A5AA0
  349.         39 00000000973A5B78
  350.         45 00000000973A5C50

  351.   COUNT(*) HLADDR
  352. ---------- ----------------
  353.         48 00000000973A5E00
  354.         44 00000000973A5ED8
  355.         42 00000000973A5FB0
  356.         42 00000000973A6088
  357.         53 00000000973A6160
  358.         54 00000000973A63E8
  359.         47 00000000973A6598
  360.         51 00000000973A6670
  361.         36 00000000973A6748
  362.         51 00000000973A69D0
  363.         53 00000000973A6B80

  364.   COUNT(*) HLADDR
  365. ---------- ----------------
  366.         29 00000000973A6C58
  367.         41 00000000973A6E08
  368.         47 00000000973A6EE0

  369. 256 rows selected.


  370. SQL> oradebug setmypid;
  371. Statement processed.
  372. SQL> oradebug dump buffers 4;
  373. Statement processed.
  374. SQL> oradebug tracefile_name;
  375. /s01/orabase/diag/rdbms/g11r23/G11R23/trace/G11R23_ora_27444.trc




  376. CHAIN: 165 LOC: 0x973a23b8 HEAD: [0x7bbd9c18,0x817faa28]
  377.   BH (0x7bfeedd8) file#: 4 rdba: 0x01027c00 (4/162816) class: 8 ba: 0x7be6a000
  378.       set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 78,22
  379.       dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
  380.       hash: [0x7bfeff28,0x7bbf29e8] lru: [0x7e7f2430,0x7bfeed90]
  381.       lru-flags: debug_dump
  382.       ckptq: [NULL] fileq: [NULL] objq: [0x7e7f1ad8,0x9207cbc0] objaq: [0x7bfef158,0x7bfeedc8]
  383.       st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
  384.       flags: block_written_once redo_since_read
  385.       LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [74]
  386.          
  387.          
  388.          


  389. CHAIN: 67 LOC: 0x9739d108 HEAD: [0x7bbdc218,0x817fb018]
  390.     BH (0x7bfd8f88) file#: 4 rdba: 0x01027c01 (4/162817) class: 8 ba: 0x7bc1c000
  391.       set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 77,22
  392.       dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
  393.       hash: [0x7bff87b8,0x7bbf6a08] lru: [0x7bfd91a0,0x7bfd8f40]
  394.       lru-flags: debug_dump
  395.       ckptq: [NULL] fileq: [NULL] objq: [0x7bfda398,0x9207ba40] objaq: [0x7bfd9b58,0x7bfd8f78]
  396.       st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
  397.       flags: block_written_once redo_since_read
  398.       LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [75]
  399.          
  400.          
  401. CHAIN: 192 LOC: 0x973a3a80 HEAD: [0x7bbdee08,0x813fa8f8]
  402.   BH (0x7e7f19c8) file#: 4 rdba: 0x01027c80 (4/162944) class: 8 ba: 0x7e6b4000
  403.       set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 78,22
  404.       dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
  405.       hash: [0x7c3fb3a8,0x7bfd99b8] lru: [0x7bfefaa0,0x7bfef840]
  406.       lru-flags: debug_dump
  407.       ckptq: [NULL] fileq: [NULL] objq: [0x7bfef868,0x7bfeeee8] objaq: [0x7bff0588,0x7bfef878]
  408.       st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
  409.       flags: block_written_once redo_since_read
  410.       LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [58]

  411. CHAIN: 94 LOC: 0x9739e7d0 HEAD: [0x7bbf0b08,0x813eec28]
  412.     BH (0x7bfda288) file#: 4 rdba: 0x01027c81 (4/162945) class: 8 ba: 0x7bc3c000
  413.       set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 77,22
  414.       dbwrid: 0 obj: 81261 objn: 81261 tsn: 4 afn: 4 hint: f
  415.       hash: [0x7bff6088,0x7bbf0b08] lru: [0x7bfda4a0,0x7bfda240]
  416.       lru-flags: debug_dump
  417.       ckptq: [NULL] fileq: [NULL] objq: [0x7bfda268,0x7bfd9098] objaq: [0x7bfdb448,0x7bfda278]
  418.       st: XCURRENT md: NULL fpin: 'ktspfwh6: ktspffbmb' tch: 2
  419.       flags: block_written_once redo_since_read
  420.       LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [59]

  421.          
复制代码
以上可以看到 在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)



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

回复 只看该作者 道具 举报

6#
发表于 2012-5-9 17:07:35
好   谢谢啊   学习了

回复 只看该作者 道具 举报

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里查看这个栓也是没有子栓的,请教一下关于这个栓的资料~

回复 只看该作者 道具 举报

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里没有子栓,它是如何工作的呢~

回复 只看该作者 道具 举报

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

回复 8# 的帖子

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

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

回复 只看该作者 道具 举报

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,还是会可能产生争用。

回复 只看该作者 道具 举报

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

回复 只看该作者 道具 举报

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

回复 只看该作者 道具 举报

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.

回复 只看该作者 道具 举报

14#
发表于 2012-5-10 09:10:24
真不错..学习了...

回复 只看该作者 道具 举报

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

回复 10# 的帖子

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

回复 只看该作者 道具 举报

16#
发表于 2012-5-10 22:04:40
maclean,看了半天还是没明白cache buffer chain与 hash chain有什么区别。
到底有几条chain?一条还是两条?是不是cache buffer chain、 hash chain是一个东西??

回复 只看该作者 道具 举报

17#
发表于 2012-5-10 22:19:59
cache buffer chain 简写为cbc 也就叫做  cache buffer hash chain

回复 只看该作者 道具 举报

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?

回复 只看该作者 道具 举报

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。不知道这样的理解是否准确??

回复 只看该作者 道具 举报

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

回复 只看该作者 道具 举报

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

回复 只看该作者 道具 举报

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

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

回复 只看该作者 道具 举报

23#
发表于 2013-12-7 10:34:48
虽然看不懂,但是感觉这个好精彩的扫盲贴,改天头脑清醒的时候学习下,O(∩_∩)O哈哈~

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

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

GMT+8, 2024-12-21 10:33 , Processed in 0.061017 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569