實驗設計思路     在進行實驗前我們先做點功課，瞭解怎麼判斷熱塊爭用以及如何評估熱塊爭用是否嚴重。     cache buffers chains鎖存器     首先需要了解下cache buffers chains鎖存器爭用，當cache buffers chains等待事件出現時，意味著出現了cache buffers chains鎖存器爭用，通常情況下，有兩種原因會出現cache buffers chains鎖存器。     原因一. 低效率的SQL語句 在某些環境中，應用程式開啟執行相同的低效率SQL語句的多個併發會話，這些SQL語句都設法得到相同的資料集。每次執行都帶有高 BUFFER_GETS(邏輯讀取)的SQL語句是主要的原因。     原因二：熱塊爭用     當多個會話重複訪問一個或多個受cache buffers chains鎖存器保護的塊時，就出現了熱塊爭用，因此我們就是通過這一特性，來定位熱塊。     本例中的SQL相對比較簡單，因此不存在複雜低效率SQL的情況，可以判斷所有cache buffers chains都為熱塊爭用導致，其可以通過動態檢視V$LATCH_CHILDREN進行查詢，其中sleeps 表示請求失敗休眠的次數，通過sleeps我們可以大體知道資料庫中latch的競爭是否嚴重，這也間接的表徵了熱點塊的問題是否嚴重。      要確定導致熱塊爭用的會話在X$BH檢視中，其中接觸點(touch count)來作為block是冷熱的標誌，那在短時間內從某種意義上講，touch count 大的block可能暗示著在當前某個週期內被訪問次數比較多。更多這方面的內容，可以參考Oracle官方文件《How To Identify a Hot Block Within The Database Buffer Cache. [ID 163424.1]》。     瞭解了判斷熱塊爭用的依據，接著搭建模擬環境，具體的實驗設計思路如下：     1.建立 TEST_普通索引表（id）表，在ID列建立普通b-tree索引test_idx索引。     2.建立TEST_反轉索引表（id）表，在ID列建立反轉鍵索引test_idx_r索引。     3.按順序插入指定量的資料。     4.建立個過程，更新資料表指定行資料，建立JOB，同一時間點通知執行該過程，保證更新的行在同一資料塊上。     5.查詢相關效能檢視，檢視熱塊爭用情況。 實驗步驟

    1.建立測試表     Create Table TEST_反轉索引表(Id Number(18));     Create Table TEST_普通索引表(Id Number(18));     2.建立索引     Create Index TEST_INDEX_R On TEST_反轉索引表(Id) Reverse;     Create Index TEST_INDEX  On TEST_普通索引表(Id);     3.按順序插入表中1000條記錄，保證連續的資料存放在相同的資料塊上。     insert into TEST_反轉索引表  select rownum from dba_objects, dba_objects  where rownum<=1000000  and rownum<1000000   order by rownum;     insert into TEST_普通索引表  select rownum from dba_objects where rownum<=1000 order by rownum;     4.為了模擬索引的爭用，我們建立一個過程，對指定的資料集中更新10萬次，在對資料更新的時候，我們知道索引的操作是先刪除舊的索引塊，然後生成新的索引塊。