Oracle教程：CR (consistent read) blocks create 說明

     The CR blocks created：  Oracle metric is the number of CURRENT blocks cloned to create CR (consistent read) blocks. The most common reason for cloning is that the buffer is held in an incompatible mode.

 

       Read consistency is used when competing processes are reading and updating the data concurrently.

 

       The gc cr block receive time： Oracle metric is the global cache cr block receive time statistic records the total time required for consistent read requests to complete. In other words, it records the accumulated round-trip time for all requests for consistent read blocks.

  

       當我們想要尋找某個資料的時候，發現這個資料區塊的版本比我們要尋找的要新，那麼我們只能從UNDO中去尋找這個資料的前映像（PRE IMAGE），在復原段中找到這個資料的前映像後，把前映像和CURRENT的資料區塊合并，就形成一個CR BLOCK，這樣，通過查詢CR BLOCK就可以得到一致性的資料了。

 

       這個CR BLOCK的產生不是在PGA裡進行的，而是要在DB CACHE裡申請一個資料區塊，然後產生CR BLOCK。這個CR BLOCK建立後，如果下一回還要訪問這個版本的資料區塊，那麼就不需要建立新的CR BLOCK，而直接可以使用以前建立的CR BLOCK了。每建立一個CR BLOCK，CR BLOCKS CREATED計數器就會增加1。

 

       由於CR BLOCK和CURRENT BLOCK的RDBA都是相同的，因此它們會被放到相同的HASH鏈上。因此如果某些BLOCK的CR BLOCK的版本過多，也會導致BUFFER CACHE CHAINS閂鎖競爭加劇。

 

有關RDBA的說明，參考我的Blog：

       Oracle rdba和 dba 說明

      

 

       如果在產生CR BLOCK的過程中，發現UNDO中的PRE IMAGE由於提交的時間比較長，已經被覆蓋，那麼，就會出現著名的ORA-1555。

 

       如果單位時間內CR BLOCKS CREATED較大，那麼應該檢查系統的CPU資源是否出現瓶頸，另外要注意檢查BUFFER CACHE相關的閂鎖，是否存在競爭。

 

buffer  Cache  chian產生原因：

       當一個會話需要去訪問一個記憶體塊時，它首先要去一個像鏈表一樣的結構中去搜尋這個資料區塊是否在記憶體中，當會話訪問這個鏈表的時候需要獲得一個Latch，如果擷取失敗，將會產生Latch cache buffer chain 等待，導致這個等待的原因是訪問相同的資料區塊的會話太多或者這個列表太長（如果讀到記憶體中的資料太多，需要管理資料區塊的hash列表就會很長，這樣會話掃描列表的時間就會增加，持有chache buffer chain latch的時間就會變長，其他會話獲得這個Latch的機會就會降低，等待就會增加）。

 

有關Latch 的更多說明，參考Blog：

       Oracle Latch 說明