37.Oracle深度學習筆記——RAC的相關等待事件

歡迎轉載，轉載請標明出處：http://blog.csdn.net/notbaron/article/details/50891037

在效能BENCHMARK中碰到的幾個等待事件：

gc cr multi block request

multi block一般情況下都是全表掃描或全索引掃描導致， gc cr multiblock request 會造成CPU 對記憶體的排程和管理，會消耗CPU時間。

當程序請求資料庫塊時，首先會在本地的CACHE裡面檢視是否存在，這種檢視是根據DBA (Data Block Address) 轉化為cache bufferschains,然後再從hash bucket確認是否存在。
如果在本地沒發現有塊的CACHE，程序就會請求resourcemaster授予共享訪問給資料塊，然後再去獲取資料塊的CACHE。
如果請求的BLOCK CACHE在遠端的節點，resourcemaster就會使用內部通訊把遠端的CACHE傳輸到本地。當請求的CACHE BUFFER是共享模式的，遠端節點就會克隆一個然後傳輸到本地。非則，就建立PI映像，然後傳輸到本地。

 這種等待產生的主要原因： 
1. 資料庫引數db_file_multiblock_read或者db_block_size設定太大，導致多塊讀時GC傳輸量太大
2. OS上UDP相關的引數設定不夠大導致接收發送UDP的快取區溢位
3. 私網效能
4. LMS設定問題（個數不足或者不是實時執行(realtime)）導致LMS的處理能力不夠，不能及時傳輸global cache data/message

gc current block 2-way:

 1.Sga 1 傳送請求道SGA2 request block  SGA1 產生gc current blockrequest .

2.SGA2 檢查這個block是否被改變 如果已被改變的話LMS  則會要求LGWR 寫redo log  （這時SGA1 會顯示busy）  然後傳送。

3.SGA2 傳送NODE 併產生Gc current block 2-way 等待 直到BLOCK 傳送到SGA1 等待終結。

當傳送NODE 過程中 對這個block的請求將會產生 GCbuffer busy.

3 way: 就是多一個節點  resource MASTER 和 cached 節點不是同一個節點。

當前塊的等待事件意味著被傳輸的塊的版本是塊的最新版本。這個等待事件讀取和寫入活動中都可能遇到。如果該塊被訪問是以讀取活動進行，那麼該資源上鎖以KJUSERPR（PR）模式獲得。剛才我在“資源和鎖定”一節中所討論的示例展示了KJUSERPR模式的鎖。

在下面的例子中，我從表t_one中查詢一行，造成連線到節點2的磁碟讀。檢視SQL跟蹤檔案，沒有全域性快取等待事件。原因是該塊被本地掌控（本地例項是master），所以FG程序中可直接獲取該資源上鎖，而不會產生任何全域性快取等待。這種型別的鎖也被稱為親和力鎖定（相似度鎖定）方案。動態掌握資源（DRM，Dynamic Resource Mastering）的部分將詳細討論相似度鎖定（親和力鎖定）。

GC CR Block 2-Way/3-Way

CR模式的塊傳輸發生在只讀訪問的請求中。考慮這樣一個場景：一個塊以CURRENT模式駐留在例項2上，例項2以獨佔模式保持了該資源的BL鎖。另一個會話連線到例項1來請求該塊，阻止。由於Oracle資料庫中“其他人看不到未提交的更改”，SELECT語句請求一個查詢開始時間的塊的特定版本。SCN被用於標識塊版本，本質上，SELECT語句請求的版本與塊的SCN一致。LMS程序維護例項2的請求，以CURRENT的模式克隆該塊到緩衝區，驗證SCN版本與請求是一致的，然後傳送該塊的CR拷貝給FG程序。

這些CR模式傳輸和CURRENT模式傳輸之間的主要區別在於，在CR模式傳輸的情況下，在GRD中沒有資源或鎖來維護CR緩衝區。從本質上講，CR模式塊不需要全域性快取資源或鎖。接收到的CR副本只能由提出請求的會話使用，並且只適用於這個特定的SQL執行中。這就是為什麼Oracle資料庫不對CR傳輸獲取BL資源的任何鎖。

由於沒有全域性快取鎖保護緩衝區，連線到例項1再次執行這個SQL語句訪問那個塊時將遭遇gc cr block 2-way 或者 gc cr block 3-way等待事件。

因此，每次從例項1訪問該塊都將觸發新CR緩衝區的構造。即使在例項2的緩衝區沒有發生該塊修改，在例項1中的FG程序仍然會遭遇到CR等待事件。駐留在例項1的CR緩衝區是不能重複使用的，因為每SQL執行請求查詢時的SCN會有所不同。

下面的跟蹤顯示了一個塊從資源主例項以0.6毫秒的延遲被傳輸到請求例項。另外，file_id，BLOCK_ID，和跟蹤檔案中的object_id資訊，可以被用來識別正在遭遇這兩個等待事件的物件。當然，也可以通過查詢ASH資料來識別該物件。

GC CR Grant 2-Way/Gc Current Grant 2-Way

如果被請求的塊沒有駐留在任何緩衝區中，就會遭遇gc cr grant 2-way 和 gc current grant 2-way等待事件。FG程序向LMS程序請求一個塊，但塊沒有駐留在任何緩衝區。因此，LMS程序回覆一條授權FG程序從磁碟讀取的塊的訊息。FG程序從磁碟讀取該塊並繼續後續的處理。

下面一行顯示了為了訪問file_id=4和lock_id=180資料塊，FG程序接收到來自LMS程序的授權響應。下一行顯示了，執行了一個從磁碟讀取塊的物理讀。

nam=’gc cr grant 2-way’ ela= 402 p1=4 p2=180p3=1 obj#=75742

nam=’db file sequential read’ ela= 553file#=4 block#=180 blocks=1 obj#=75742

過多的此類等待意味著，要麼緩衝區快取記憶體太小，要麼SQL語句的執行過分的重新整理了緩衝區快取記憶體。識別正在遭遇此類等待事件的SQL語句和物件，並優化這些SQL語句。

DRM功能的設計就是為了減少發生這類授權相關的等待事件。

GC CR Block Busy/GC Current Block Busy

繁忙事件（Busy events）表明，LMS執行了額外的工作去處理併發相關的問題。例如，要建立一個CR塊，LMS程序可能要應用撤消記錄（undo records），重構一個與查詢的SCN一致的塊。在把該塊回傳給FG過程時，LMS將標記塊傳輸是否遇到gc cr block busy或gc current block busy等待事件，這取決於塊傳輸的型別。

GC CR Block Congested/GC Current Block Congested

如果LMS程序在接收到請求後沒有在1毫秒內處理該請求，那麼LMS程序標記這個響應為：該塊正遭遇擁堵相關的等待事件。堵塞相關的等待事件有很多原因，比如說，LMS程序被大量全域性快取記憶體的請求所淹沒。LMS程序正遭遇CPU的排程延遲，LMS程序已經遇到了另一種資源耗盡（如記憶體）等。

通常情況下，LMS程序執行在實時CPU排程優先順序，因此，CPU排程的延遲將是最小的。大量這類的等待此事件表明出現了全域性快取請求的突然飆升，且LMS程序無法快速處理這些請求。伺服器記憶體匱乏也可能導致LMS程序的分頁，影響全域性快取的效能。

再分享一下我老師大神的人工智慧教程吧。零基礎！通俗易懂！風趣幽默！希望你也加入到我們人工智慧的隊伍中來！http://www.captainbed.net