減少熱塊沖突的方法

實際上今天要討論的內容在之前也零零星星討論過,，只是想通過今天的討論，加深大家的印象,。熱塊沖突是最為常見的現象,，是DBA討論最多的，不過也是DBA做的最少的部分,。幾乎所有的系統(tǒng)都存在熱塊沖突的問題,，只是嚴重程度不同而已，一般系統(tǒng)的熱塊沖突對系統(tǒng)造成的影響都小于5%,，因此絕大多數DBA對此采取了容忍的態(tài)度,。實際上大多數的熱塊沖突都可以通過應用方面的優(yōu)化來解決。解決熱塊沖突最為有效地方法除了修改SQL外,，就是通過調整表的存儲結構來解決,。

為了探討今天的話題，我們首先需要了解一下什么是熱塊沖突,，熱塊沖突有哪些形式,。首先要聲明的是，本節(jié)的討論時圍繞著表這個話題的,，解決熱塊沖突的方法有很多,，我們會在今后的很多話題中再次討論熱塊沖突，在這里我們主要討論如何通過優(yōu)化表的結構來減少熱塊沖突,。

談到熱塊沖突我們首先需要了解熱塊沖突發(fā)生的原因,，這一點從Oracle對buffer busy waits這個等待事件的定義上可以看出一些端倪：

Buffer Busy Waits ID's and MeaningsReason Code (Id) Reason 

<=8.0.6 8.1.6-9.2 >=10.1 

0 0 n/a A block is being read 

1003 100 n/a We want to NEW the block but the block is currently being read by another session (most likely for undo). 

1007 200 n/a We want to NEW the block but someone else has is using the current copy so we have to wait for them to finish. 

1010 230 n/a Trying to get a buffer in CR/CRX mode , but a modification has started on the buffer that has not yet been completed. 

1012 - n/a A modification is happening on a SCUR or XCUR buffer, but has not yet completed 

1012 (dup.) 231 n/a CR/CRX scan found the CURRENT block, but a modification has started on the buffer that has not yet been completed. 

1013 130 n/a Block is being read by another session and no other suitable block image was found e.g. CR version, so we wait until the read is completed. This may also occur after a buffer cache assumed deadlock. The kernel can't get a buffer in a certain amount of time and assumes a deadlock. Therefore it will read the CR version of the block. This should not have a negative impact on performance, and basically replaces a read from disk with a wait for another process to read it from disk, as the block needs to be read one way or another. 

1014 110 n/a We want the CURRENT block either shared or exclusive but the Block is being read into cache by another session, so we have to wait until their read() is completed. 

1014 (duplicate) 120 n/a We want to get the block in current mode but someone else is currently reading it into the cache. Wait for them to complete the read. This occurs during buffer lookup. 

1016 210 n/a The session wants the block in SCUR or XCUR mode. If this is a buffer exchange or the session is in discrete TX mode, the session waits for the first time and the second time escalates the block as a deadlock and so does not show up as waiting very long. In this case the statistic: "exchange deadlocks" is incremented and we yield the CPU for the "buffer deadlock" wait event. 

1016 (duplicate) 220 n/a During buffer lookup for a CURRENT copy of a buffer we have found the buffer but someone holds it in an incompatible mode so we have to wait. 

 BUFFER BUSY WAITS等待事件的三個參數中的前兩個是文件號和數據塊號，第三個參數8.0-9.2都是等待原因,，從10.1開始,，第三個參數的含義變成了block的類別（BLOCK CLASS#）。一般來說,，buffer busy waits產生的主要原因有幾個方面：

l         訪問某個數據塊的時候其他會話正在將該數據塊讀入db cache,，如果IO系統(tǒng)存在性能問題，那么會加重這種類型的等待。10g中將這種buffer busy waits獨立為另外一個等待事件：read by another session,，這個名稱就更為直觀了

l         訪問某個數據塊的時候,，這個數據塊被其他會話以不兼容的模式所持有

產生等待的BUFFER可能是段頭（Segment Header），也可能是數據塊,，UNDO數據塊等,。段頭可能由于大量的并發(fā)插入導致freelists的等待或者ASSM下段頭里的位圖塊（bmb block）等待。對待每種類型的buffer busy waits我們的處理方法也是不同的,。

對于SEGMENT HEADER的等待,，一般來說主要集中在FREELISTS或者BMB上，我們可以通過調整FREELISTS,FREELIST GROUPS等參數來解決,。如果等待集中在BMB上,，那么一般來說只能通過使用分區(qū)表或者調整應用等手段來解決了。本節(jié)我們重點討論如何減少表數據塊上的熱塊沖突,。

說起解決數據庫熱塊沖突的辦法,，實際上我們有兩條路，第一條路是從應用的角度減少熱塊沖突,，第二條路是減少熱塊對系統(tǒng)的影響,。在任何一個系統(tǒng)中，熱塊沖突是避免不了的,，因此我們在日常做優(yōu)化的時候,，首先應該考慮是否有可能減少熱塊沖突帶來的影響。順著這個思路,，我們可以發(fā)現實際上有一些這方面的手段,，比如提高DB CACHE的命中率（一般通過加大DB CACHE的大小來實現）、使用多緩沖區(qū)技術等等,。在我經歷過的案例中,，至少有30%的案例是通過上述手段就解決了問題的。采用這些手段解決問題代價比較小,，不需要花大力氣去分析應用,。

前面我們也討論過，增加INITRANS參數可以有效避免由于事務槽等待而產生的熱塊沖突,。加大PCTFREE的值,，可以使每個數據塊存儲的記錄數減少，從而減輕熱塊沖突,。比加大PCTFREE更為徹底的方法是將表存儲在BLOCK_SIZE更小的表空間上,。

如果數據塊本身存在熱點怎么處理呢？這個問題回答起來有點麻煩,，因為既然是數據,，那么數據就是多樣性的，沒有一種辦法是能夠解決問題的靈丹妙藥。除了我們剛才所說的方法可以緩解熱塊沖突外,，oracle還提供了一系列的手段,。最為典型的是hash分區(qū)表和hash簇表。

HASH分區(qū)表是解決熱塊沖突的一種較為常用的辦法,，對于表數據量較大的情況,，可以考慮采用HASH分區(qū)表。比如有一張表,，主鍵是通過SEQUENCE產生的,，那么在沒有使用HASH分區(qū)表的情況下，同一個時間點產生的記錄存儲在同一個數據塊中的可能性很大,。而這些數據隨后又被其他應用使用,，這樣產生熱塊的機會就很高了,。如果我們將這張表根據主鍵設計成HASH分區(qū)表,，那么同一個時刻產生的記錄就被HASH算法分布到不同的表分區(qū)中去了，訪問這些數據的時候就可以從多個數據塊中讀取,，從而緩解了熱塊沖突,。

既然HASH分區(qū)表這么強，很定有些朋友會蠢蠢欲動了,，干脆我把存在熱塊爭用的表都設計成HASH分區(qū)表好了,。實際上任何技術都有其兩面性，HASH分區(qū)表解決了熱塊沖突的問題,，但是帶來了另外一個問題,，如果我們的應用總是通過主鍵來訪問這張表的數據，那么這種方式確實是最好的,。但是如果我們還有大量的應用需要根據主鍵進行范圍掃描,，或者按照記錄的生成日期進行范圍掃描，那么HASH分區(qū)表的弱點就顯現出來了,。原本放在同一個數據塊中的數據被HASH 算法分散開了,，這同時意味著我們對這些數據做范圍掃描的時候需要掃描更多的數據塊。這就是HASH分區(qū)表的弱點,，增加了范圍掃描的成本,。

在實際的生產環(huán)境中，我們可能不總是那么幸運,，我們肯定會碰到兩方面的需求,。一方面是熱塊沖突必須解決，另外一方面可能我們還存在一定的應用要對這些數據做范圍掃描,。在這種情況下,，我們必須進行綜合的評估，到底哪種需求是主要需求。如果我們優(yōu)化范圍掃描對系統(tǒng)更為有利,，那么我們就必須放棄HASH分區(qū),；如果解決熱塊沖突更為重要，那么我們就必須犧牲范圍掃描,。實際上Oracle就是這樣的,，任何技術都是矛盾的，都是有缺陷的,，否則我們就只需要記住一些準則,，就可以成為大師了。Oracle的大師不是那么容易當的,，因為在絕大多數情況下,，沒有永恒的準則。

文章出處：飛諾網(www.):http://dev./course/7_databases/oracle/oraclexl/20100804/524688.html