等待事件：read by other session

一、等待事件介紹

This event occurs when a session requests a buffer that is currently being read into the buffer cache by another session. Prior to release 10.1, waits for this event were grouped with the other reasons for waiting for buffers under the 'buffer busy wait' event

Wait Time: Time waited for the buffer to be read by the other session (in microseconds)

這個事件發生在一個資料塊正在被讀進buffer，而其它session此時也要請求這個資料塊的時候。這個事件10G以前被歸類在buffer busy wait的其他類目中。

二、檢視資料庫read by other session和db file sequential read的等待事件的資訊

指令碼：

三、檢視read other session和db file scattered read事件相關語句的SQL_ID

四、檢視相關語句的執行計劃

可以看到相關SQL確實在對該表做索引掃描的操作，耗時達到23分鐘。

五、解決方法

1、對SQL語句進行調優；

2、調節資料庫的buffer cache，因為這個過程是指記憶體中找不到相應的資料，所以要從磁碟把資料讀取到共享記憶體，如果是由於buffer cache太小的話，增加buffer cache的大小便可以解決這個問題（需要參照awr報告中的記憶體命中率情況）

附加：

Read By Other Session詳細原理說明：這個等待在10G前就是Buffer Busy Waits等待的一種情況，10G後把這個等待從Buffer Busy Waits等待的劃分了出來。總的來說，這個等待的發生在由於：程式（我們假設程式A）需要訪問的資料塊不在記憶體裡，因此不得不把資料塊從磁碟LOAD到記憶體的過程中，另一個/些（假設程式B、C）也要讀取這個資料塊，這個時候程式A發生的等待可能是db file sequential read/db file parallel read/db file scattered read中的某一個或某幾個，而程式B、C發生的等待就是我們今天要介紹的Read By Other Session，Oracle不會讓多個程式去同時物理讀取一個資料塊LOAD入共享記憶體，只會讓第一個程式去DISK讀取，然後放入共享記憶體，這麼做也是為了保護共享記憶體。

步驟大致如下：1）Oracle計算出查詢所要請求資料塊的地址，然後根據地址+塊類計算出塊所在buffer cache的Hash Bucket Number，然後獲取到保護這個Hash Bucket的CBC Latch，在持有CBC Latch的情況下，在Hash Bucket裡尋找目標Block是否存在在Bucket裡，最終沒有找到，釋放CBC Latch。（可能Oracle 實際發生的情況與我描述的不符，看最後的解釋）。2）申請Lru Latch，搜尋Lru-Aux連結串列找尋空閒塊。其實這個連結串列是以buffer header上的指標串起來的，buffer header上還有指向buffer block的指標，找到後，修改buffer header的某些條目，比如把block address的資訊設定上去，指向記憶體裡的某個buffer，主要是標示記憶體裡的這個塊已經被使用了。3）再次獲取正確的CBC Latch，把這個buffer header連結到正確的hash chain上去，也就是把它放到正確的hash bucket裡去。4）以排他的x模式去pin這個buffer。這樣別的會話就能知道這個buffer還不能訪問。5）釋放Lru Latch，CBC Latch.6）開始物理讀取，這個時候前臺程式等待db file sequential read/db file parallel read/db file scattered read ，具體等待那一種，看讀取的型別，也可能會出現多種等待。7）在物理讀取期間，如果有其他會話也想訪問這個資料塊，等待Read By Other Session 。8）讀取結束後，申請CBC Latch，unpin這個buffer，釋放CBC Latch。

10G前把這個等待歸入到了Buffer Busy Waits等待裡，這麼歸類也是有道理的：Buffer Busy Waits等待的本質是由於欲獲得buffer lock的會話由於申 請的鎖模式跟buffer上已經存在的鎖模式衝突導致的。而read by other session也符合這一核心要點。物理讀取資料塊的程式在對應的buffer上加了x模式的buffer lock，其他程式想要以s模式讀取資料塊，由於x模式的buffer lock，與任何其他鎖模式都不相容，因此產生了read by other session等待，也就是10G前的buffer busy waits等待中的一種情形。直接路徑讀取會不會產生read by other session？不會的，直接路徑讀取把資料讀取在程式自己的PGA裡，不涉及到共享記憶體的佔用，這種情況下，即使有併發，各個程式間的等待也只是 direct path read。步驟1我的描述裡，程式在發現資料塊不在記憶體後，釋放了CBC Latch，然後去申請Lru Latch,獲得空閒記憶體塊後，再次去持有CBC Latch，而這個過程也非常可能是程式在發現資料塊不在記憶體後，不釋放CBC Latch，直接去持有Lru Latch。至於到底是哪個過程，我就不做驗證了，有興趣的可以去手工的持有latch驗證下。我個人覺得不釋放CBC Latch，直接去持有Lru Latch的可能性比較大:1）這樣省去了釋放CBC Latch最後又獲得一次CBC Latch的資源消耗 2）Lru的Latch的級別設計的比CBC Latch級別高，因此在持有CBC Latch的情況下再去持有Lru Latch更顯得順理成章。當然這個只是我YY，理論上持有Lru Latch情況下，以immediate 方式去申請CBC Latch也是可以的。這裡只是給大家大體介紹一下這個等待的一些基本情況，更深的細節暫時就不過多研究了。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

本文作者：JOHN

ORACLE技術部落格：ORACLE 獵人筆記               資料庫技術群：367875324 （請備註ORACLE管理 ）  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12679300/viewspace-1208646/，如需轉載，請註明出處，否則將追究法律責任。