shared pool 和buffer pool 详解（之二， Cache Buffers LRU Chain、Cache Buffers LRU Chain闩锁竞争与解决）
【深入解析--eygle】學習筆記
?
1.1.2? Cache BuffersLRU Chain閂鎖競爭與解決
?
當用戶進程需要讀數(shù)據(jù)到Buffer Cache時或Cache Buffer根據(jù)LRU算法進行管理等，就不可避免的要掃描LRU? List獲取可用Buffer或更改Buffer狀態(tài)，我們知道，Oracle的Buffer Cache是共享內(nèi)存，可以為眾多并發(fā)進程并發(fā)訪問，所以在搜索的過程中必須獲取Latch（Latch是Oracle的一種串行鎖機制，用于保護共享內(nèi)存結(jié)構(gòu)），鎖定內(nèi)存結(jié)構(gòu)，防止并發(fā)訪問損壞內(nèi)存中的數(shù)據(jù)（我們必須認識到對于數(shù)據(jù)的訪問、Buffer的存取就意味著多次的Latch訪問，而過于嚴重的Latch競爭常常是系統(tǒng)的瓶頸所在）。
這個用于鎖定LRU的Latch就是我們經(jīng)常見到的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，這樣可以減少讀數(shù)據(jù)到Buffer Cache的機會，減少掃描Lru List的競爭。
（2）? 可以適當增加LRULatch的數(shù)量，修改_db_block_lru_latches參數(shù)可以實現(xiàn)，但是該參數(shù)通常來說是足夠的，除非在Oracle Support的建議下或確知該參數(shù)將帶來的影響，否則不推薦修改。
（3）? 通過多緩沖池技術，可以減少不希望的數(shù)據(jù)老化和全表掃描等操作對于Default池的沖擊，從而可以減少競爭。
（4）? 優(yōu)化SQL，減少數(shù)據(jù)讀取，從而減少對于LRU List的掃描。
?
2.1.3 Cache Buffer Chain閂鎖競爭與解決
在LRU和Dirty List這兩個內(nèi)存結(jié)構(gòu)之外，Buffer Cache的管理還存在另外兩個重要的數(shù)據(jù)結(jié)構(gòu)：Hash Bucket和Cache Buffer Chain。
?
1．Hash Bucket和Cache Buffer Chain
我們可以想象，如果所有的Buffer Cache中的所有Buffer都通過同一個結(jié)構(gòu)管理，當需要確定某個Block在Buffer中是否存在時，將需要遍歷整個結(jié)構(gòu)，性能會相當?shù)拖隆?/p>
為了提高效率，Oracle引入了Bucket的數(shù)據(jù)結(jié)構(gòu)，Oracle把管理的所有的Buffer通過一個內(nèi)部的Hash算法運算后存放到不同Hash Bucket中，這樣通過Hash Bucket進行分割之后，眾多的Buffer被分布到一定數(shù)量的Bucket之中，當用戶需要在Buffer中定位數(shù)據(jù)是否存在時，只需要通過同樣的算法獲得Hash值，然后到相應的Bucket中查找少量的Buffer即可確定。
?
每個Buffer的存放的Bucket由Buffer的數(shù)據(jù)塊地址（DBA，Data Block Address）運算決定。在Bucket內(nèi)部，通過Cache Buffer Chain（它是一個雙向鏈表）將所有的Buffer通過BufferHeader信息聯(lián)系起來。
Buffer Header存放的是對應數(shù)據(jù)塊的概要信息，包括數(shù)據(jù)塊的文件號、塊地址、狀態(tài)等。在判斷數(shù)據(jù)塊在Buffer中是否存在，通過檢查Buffer header即可確定。
?
讓我們通過一個現(xiàn)實的場景來回顧一下這個過程。
如果大家去過老一點的圖書館，查找過手工索引，你可能記得這樣的場景：樹立在你面前的是一排柜子（那是相當?shù)膲延^），柜子又被分為很多小的抽屜，抽屜上按照不同的分類方法標注了相關信息，比如按開頭字母順序，如果我們要查詢Oracle相關書籍，就需要找到標記有“O”的 抽 屜 。打 開 抽 屜 ，我們 會 看 到 一 系 列 的 卡 片 ，這 些 卡 片 通 常 被 一 根鐵閂串起來（通常就是一個鐵絲），每根卡片上會記錄相關書籍的信息，可能包括書籍名稱、作者、ISBN號、出版日期等，當然這些卡片上還存儲了一個重要的信息，就是書籍存放的書架位置信息，有了這個信息，通過翻閱這些卡片，就可以快速地找到想要的書籍，并且 在 需 要 時 能 夠 快 速 從 圖 書
?
館浩如煙海的圖書中找到我們需要的一本。
?
在這里，圖書館就是我們的Buffer Cache，這個Cache可能因為“圖書數(shù)量”的增加而不斷擴大；每個抽屜都是一個Bucket，這個Bucket中存放了根據(jù)一定的分類方式（也就是通過Hash運算）歸入的圖書信息，也就是Buffer Header；抽屜中的每張卡片就是一個Buffer Header，這些Buffer? Header上記錄了關于數(shù)據(jù)塊的重要信息，如DBA等；這些卡片在Bucket中，通過一個鐵閂串接起來，這就是Cache Buffer Chain
?
由于每個抽屜只有一根鐵閂，如果很多同學都想翻閱這個鏈上的卡片，那么就產(chǎn)生了Cache? Buffer? Chain的競爭，先來到那個同學持有了Latch就能不停的翻閱，其他同學只好不停的來檢查，當然如果檢查次數(shù)多了（超過了_spin_count）， 也 可 以 去 休 息 室 小 憩 一 會 ， 再來和其他同學爭奪。
從Oracle 9i開始,對于Cache Buffer Chain的只讀訪問，其Latch可以被共享。也就是說，如果大家都只是翻一翻卡片，那么大家可以一起讀，但是如果有人要借走這本書，那么就只能獨享這個Latch了。這就是Buffer Cache與Latch競爭。
?
由于Buffer根據(jù)Buffer? Header進行散列，最終決定存入那一個Hash? Bucket，那么Hash Bucket的數(shù)量在一定程度上決定了每個Bucket中Buffer數(shù)量的多少，也就間接影響了搜索的性能。所以在不同版本中，Oracle一直在修改算法，優(yōu)化Hash Bucket的數(shù)量。我們可以想象， Bucket的數(shù)量多一些，那么在同一時間就可以有更多的同學可以拿到不同的抽屜，進行數(shù)據(jù)訪問；但是更多的抽屜，顯然需要更多的存放空間，更多的管理成本，所以優(yōu)化在什么時候都不是簡單的一元方程。
Hash Bucket的設置受一個隱含參數(shù)_ DB_BLOCK_HASH_BUCKETS的影響。在Oracle 7和Oracle 8中，該參數(shù)缺省值為DB_BLOCK_BUFFERS/4的下一個素數(shù)。
通過以上的討論可以知道，對應每個Bucket，只存在一個Chain，當用戶試圖搜索Cache Buffer Chain時，必須首先獲得Cache Buffer Chain Latch。那么Cache BufferChain Latch的設置就同樣值得研究了
?
我們看到，從Oracle? 8i 開始，_db_block_hash_buckets 的數(shù)量較以前增加了8 倍，而_db_block_hash_latchs的數(shù)量增加有限，這意味著，每個Latch需要管理多個Bucket，但是由于Bucket數(shù)量的多倍增加，每個Bucket上的Block數(shù)量得以減少，從而使少量Latch管理更多Bucket成為可能。
?
?
?
總結(jié)一下上圖中所描述的內(nèi)容。
（1）? 從Oracle8i開始，Bucket的數(shù)量比以前大大增加；通過增加的Bucket的“稀 釋 ”使得每個Bucket上的Buffer數(shù)量大大減少。
（2）? 在Oracle8i之前，_db_block_hash_latches的數(shù)量和Bucket的數(shù)量是一致的，每個Latch管理一個Bucket；從Oracle 8i開始每個Latch需要管理多個Bucket，由于每個Bucket上的Buffer數(shù)量大大降低，所以Latch的性能反而得到了提高。
（3）? 每個Bucket存在一條Cache Buffer Chain。
（4）? Buffer Header上存在指向具體Buffer的指針。
?
?
2．X$BH與Buffer Header
Buffer? Header數(shù)據(jù)，可以從數(shù)據(jù)庫的字典表中查詢得到，這張字典表是：X$BH。X$BH中的BH就是指Buffer Headers，每個Buffer在x$bh中都存在一條記錄
?
Buffer? Header中存儲每個Buffer容納的數(shù)據(jù)塊的文件號、塊地址、狀態(tài)等重要信息，可以將Buffer Header看作是Buffer的“名片”，通過這張名片，Buffer的重要信息得以展現(xiàn);
下圖包含了Buffer Header上記錄的信息，Hash Bucket上的Chian連接起這些BH。
?
?
?
根據(jù)Buffer? Header上記錄的這些信息，結(jié)合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的訪問次數(shù)， Buffer被訪問的次數(shù)越多，說明該Buffer越“搶手”，也就可能存在熱點塊競爭的問題。
以下通過幾個簡單的查詢。以下查詢用于獲得當前數(shù)據(jù)庫最繁忙的Buffer：
?
SELECT *
? FROM(SELECT addr, ts#, file#, dbarfil, dbablk, tch
?????????FROM x$bh
????????ORDER BY tch DESC)
?WHERE ROWNUM < 11;
?
?
?
再結(jié)合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的轉(zhuǎn)儲信息中，看到Buffer Header的具體內(nèi)容，以下信息來自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之前，數(shù)據(jù)庫的等待事件中，所有Latch等待被歸入Latch Free等待事件中，在Statspack的report中，如果在Top 5等待事件中看到Latch Free這一等待處于較高的位置，就需要DBA介入進行研究和解決。
?
3．熱點塊競爭與解決
接下來將通過一個環(huán)境的實際情況對熱點塊的問題進行分析和探討。
Top 5等待事件都值得關注。注意到這個數(shù)據(jù)庫中Latch Free是最嚴重的競爭。
由于Latch? Free是一個匯總等待事件，我們需要從v$latch視圖獲得具體的Latch競爭主要是由哪些Latch引起的。
如果cache buffers chains正是主要的Latch競爭。實際上，如果數(shù)據(jù)庫在繁忙的時段，基本上處于停頓狀態(tài)，大量進程等待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進行關聯(lián)，這樣就可以把具體的Latch競爭和數(shù)據(jù)塊關聯(lián)起來，再結(jié)合dba_extents視圖，就可以找到具體的熱點競爭對象。
到具體熱點競爭對象之后，可以進一步地結(jié)合v$sqlarea或者v$sqltext視圖，找到頻繁操作這些對象的SQL，對其進行優(yōu)化，就可以緩解或解決熱點塊競爭的問題。通過以下查詢可以實現(xiàn)以上的思想，獲取當前持有最熱點數(shù)據(jù)塊的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>
?
?
結(jié)合v$sqltext或v$sqlarea，可以找到操作這些對象的相關SQL，讓我們繼續(xù)查詢：
?
?
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之后，剩下的問題就簡單了，可以通過優(yōu)化SQL減少數(shù)據(jù)的訪問，避免或優(yōu)化某些容易引起爭用的操作（如connect by等操作）來減少熱點塊競爭。
?
?
?
?
?
?
總結(jié)
以上是生活随笔為你收集整理的shared pool 和buffer pool 详解（之二， Cache Buffers LRU Chain、Cache Buffers LRU Chain闩锁竞争与解决）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Scrapy-redis实现分布式爬取的
- 下一篇： Lazarus安装使用