Oracle RAC Wait Events

Oracle RAC Wait Events

本文來自：

《 Oracle database 11g RAC 手冊》 ---10.7 Oracle RAC 等待事件

《Real Application Clusters Administration and Deployment Guide》

叢集等待事件屬於以下類別之一：

(1) 面向塊的等待

(2) 面向訊息的等待

(3) 面向爭用的等待

(4) 面向負載的等待

1.  面向塊的等待

面向塊的等待是最常見的叢集等待事件。面向塊的等待事件統計資訊表明所請求的塊是從其他例項提供的。在兩節點叢集環境中，一條訊息被傳送到塊的當前擁有者，這個擁有者將塊傳遞給請求者。在具有兩個以上節點的叢集環境中，這個快的請求透過資源主控者傳遞給塊的擁有者，其中擁有附加資訊。

這些事件通常在沒有塊爭用時最為頻繁，等待時間長度區域於它在物理網路上花費的時間、在服務例項中處理請求的時間、在資料庫到達之後喚醒請求程式所花費的時間。

如果這些特定的等待對效能具有嚴重影響，那麼應當考慮平均等待時間和總等待時間。我們通常會發現，互聯問題、負載問題或針對大型共享工作集執行SQL操作可能是根本原因。

下面是最常見的面向塊的等待：

1 gc current block 2-way

2 gc current block 3-way

3 gc cr block 2-way

4 gc cr block 3-way

1.  gc current block 2-way

一個例項請求對當前節點中的一個資料庫進行授權，以修改該資料塊。主控相應資源的例項接收到這一請求。主控者擁有這個塊的當前版本，透過“快取融合機制”將這個資料塊的當前版本發生到請求者。這個事件表明存在“寫/寫”爭用。

   Gc current block 2-way出現不一定表明存在效能問題，它只是表明這些例項只是在訪問對方快取中的資料副本，但是，如果每個事件的平均等待時間非常長，那可能會影響效能，需要進一步分析。

(1) 分析爭用。AWR中Current Blocks Received部分內容應當可以幫助確認爭用嚴重的物件。

(2) 確保對爭用最嚴重的物件採用了良好的資料庫物件設計實踐、資料庫物件佈局和空間管理實踐。

(3) 使用適當的應用程式分割槽方案，對應用程式爭用進行最佳化。

 

2.  gc current block  3 -way

一個例項請求以當前模式訪問一個資料塊的授權。主控相應資源的例項接收請求，並將訊息轉發給當前擁有者，告訴他放棄所有權。這個擁有例項透過快取融合機制將資料塊當前版本的副本傳送給請求方，並將獨佔鎖傳送給發出請求的例項。這個事件表明存在“寫/寫”爭用。

 

3.  gc cr block 2-way

一個例項請求以CR模式訪問一個資料塊的授權。主控相應資源的例項接收這個請求。這個主控者擁有這個資料塊的當前版本。它是以當前塊和它擁有的撤銷資料製作CR副本，並透過互聯將這個塊的CR副本傳送到請求方，這個事件表明存在“寫/讀”爭用。

如果這個等待事件出現在“前5個最耗時的事件”列表中，那麼可執行以下操作：

(1) 分析爭用。AWR報告中的“Segment by CR Blocks Received”部分應當可以幫助確定爭用最嚴重的物件。

(2) 使用適當的應用程式分割槽方案，對應用程式爭用進行最佳化。

    

4.gc cr block 3-way

一個例項請求以CR模式訪問一個資料塊的授權。主控相應資源的例項接收此請求。主控者將請求轉發給這個塊的當前擁有者。這個擁有例項透過快取融合機制將這個資料塊的CR副本傳送給請求方。這個事件表明存在“寫/讀”爭用。

 

2.  面向訊息的等待

面向訊息的等待事件統計資訊表明沒有接收到資料塊。原因是在任何例項中沒有快取它。但對發出請求的例項授予全域性訪問許可權，允許它從磁碟中讀取資料塊或者修改它。這些等待之後通常跟著一個磁碟讀取事件，如db file sequential read或db file scattered read。

如果這些等待事件佔用的時間很長，那麼可以假定是頻繁執行的SQL導致了大量磁碟I/O（在cr授權情況下），或者是工作量插入了大量資料，需要經常查詢和格式化新塊（在當前授權情況下）。

下面是最常見的面向訊息的等待：

1 gc current grant 2-way

2 gc current grant 3-way

3 gc cr grant 2-way

4 gc cr grant 3-way

1  gc current grant 2-way

當一個例項需要當前模式的一個資料塊時，它將這個請求傳送給主控例項，主控例項發現所有例項(包含它自己在內)目前都沒有鎖定被請求的塊。向發出請求的例項發回一條訊息，授予它對這個資料塊的共享鎖。發出請求的例項隨後從磁碟中讀取塊。這一事件不代表任何爭用。

 

如果這個等待事件出現在“前5個最耗時的事件”列表中，那麼表明這個例項在獲取鎖時花費大量事件。下面給出應當採取的操作列表：

對SQL進行調優，以最佳化這個應用程式訪問的塊數，從而減少它請求的塊數。

3 面向爭用的等待

面向爭用的等待事件統計資訊表明所接收的塊是由另一個節點上的會話固定的，由於還沒有向磁碟重新整理某一修改，因此該資料庫被延遲，或者因為高度併發而被延遲。從而可能無法立即交付。這種等待事件通常在對索引塊執行併發DML操作時發生，當索引塊在擁有者中保持頻繁狀態時，其他例項需要等待當前塊新增索引項。在這種情況下，在面向爭用的等待gc current block busy後面會跟著gc current split或gc buffer busy事件。

如果一個會話已經啟動了一個“快取融合”操作並等待這一操作的完成，而同一個節點上的另一個會話正在嘗試讀取和修改同一資料，那麼一個緩衝區可能會是本地頻繁的。在Oracle 11g中可能發生這種等待，例如前臺程式正在等待反對鎖廣播更新主讀(read-mostly)物件。

如果在全域性快取中交換資料塊所花費的服務時間過長，那麼可能使爭用進一步加劇。

下面是最常見面向爭用的等待：

1 gc current block busy

2 gc cr block busy

3 gc buffer busy acquire/release

   等待事件block busy意味著“某一個”會話請求訪問一個特定的資料庫，而這個資料塊在一個遠端節點上(因為前面給出的各種原因)被認為處於“繁忙”狀態。“緩衝區忙”意味著“多個”會話正在等待一個遠端節點上的“繁忙”的資料塊。換句話說，“緩衝區忙”的情景涉及多個因為同一資料塊而導致爭用的會話，所需要的調優方法類似於處理“buffer busy waits”或“read by other sessions”事件，只不過是在Oracle RAC環境中進行處理。

1 gc current block busy

當一個請求需要當前模式的資料塊時，它向主控例項傳送一條請求。這個請求最終透過快取融合傳送獲得資料塊：但是，由於以下原因之一會使資料塊傳遞延遲：

(1)  這個塊正被另一個例項上的會話使用。

(2)  由於擁有這個資料塊的例項不能馬上將相應的重做記錄寫到聯機重做日誌中，因此資料塊傳遞被延遲。

我們可以使用會話級別的動態效能檢視v$session 和 v$session_event 來查詢導致這一事件最長等待時間的程式和會話：

Select e.sid, e.time_waited, s.program, s.module

  from v$session_event e, v$session s

 Where s.sid = e.sid

   and e.event = 'gc current block busy'

 order by e.time_waited;

Select st.sid, st.value, s.program, s.module

  from v$sesstat st, v$session s, v$statname n

 where s.sid = st.sid

   and st.statistic# = n.statistic#

   and n.name = 'gc CPU used by this session'

 order by st.value;

在解讀這個查詢結果時，一定要多加小心，因為一個會話執行的時間越長，總等待時間和統計資訊的值越大。為了消除這個謬誤，應當將這個查詢執行多次，間隔幾秒執行一次，並對比其差值( 也就是說，不要對比絕對值 ) 。在確認了一些可能導致效能問題的會話之後，應當將分析的重點放在這些會話的所有等待事件和統計資訊上。

這個事件表明存在嚴重的寫/ 寫爭用。如果這個事件出現在 AWR 前 5 個最耗時事件列表中，那麼進行如下操作：

確保對日誌寫入程式LGWR 進行了調優。

利用適當的應用程式 分割槽來避免爭用。

2  gc cr block busy

這個事件與gc current block busy事件相同，只是在這種情況下，發出請求的事件已經請求CR模式的塊。

3  gc buffer busy acquire/release

11g開始將gc buffer  busy分為gc buffer busy acquire和gc buffer  busy release:

https://blog.csdn.net/stevendbaguo/article/details/46323279

gc buffer busy acquire是當session#1嘗試請求訪問遠端例項(remote  instance) buffer，但是在session#1之前已經有相同例項上另外一個session#2請求訪問了相同的buffer，並且沒有完成，那麼session#1等待gc buffer busy acquire。
     gc buffer busy release是在session#1之前已經有遠端例項的session#2請求訪問了相同的buffer，並且沒有完成，那麼session#1等待gc buffer busy release。

原因/解決方法
---------------------
- 熱點塊(hot block)
在AWR中Segments by Global Cache Buffer Busy 記錄了訪問頻繁的gc buffer.
解決方法可以根據熱點塊的型別採取不同的解決方法，比如採取分割槽表，分割槽索引，反向index等等。這點與單機資料庫中的buffer busy waits類似。

- 低效SQL語句
低效SQL語句會導致不必要的buffer被請求訪問，增加了buffer busy的機會。在AWR中可以找到TOP SQL。解決方法可以最佳化SQL語句減少buffer訪問。這點與單機資料庫中的buffer busy waits類似。

- 資料交叉訪問
RAC資料庫，同一資料在不同資料庫例項上被請求訪問。
如果應用程式可以實現，那麼我們建議不同的應用功能/模組資料分佈在不同的資料庫例項上被訪問，避免同一資料被多個例項交叉訪問，可以減少buffer的爭用，避免gc等待。

- Oracle bug
建議安裝Oracle推薦的最新Patch Set和PSU。
Patch set和PSU資訊請參考：Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)

4 面向負載的等待

    面向負載的等待事件表明已經在GCS中發生了處理延遲，它通常是由於負載過高、CPU飽和導致的，必須透過新增CPU、負載均衡或者在不同時間進行解除安裝處理或轉移到新叢集節點等方法加以解決。對於新提及的事件，等待時間包括從會話在發出塊請求後開始等待的時候算起。直到資料塊到達時刻所經歷的整個往返時間。

無論是塊傳輸請求，還是訊息傳輸請求，只要它在程式間通訊(IPC)層之後的內部佇列中的等待時間超過一毫秒，就認為這個系統“過載”。這一現象的典型發生情景是：一個LMS程式無法跟上到達速度，從而使訊息排隊等待LMS處理。

在一個良好負載均衡的叢集環境中，應當很少看到擁塞等待。下面是最常見的面向負載的等待，這些等待的存在意味著系統過載或者能力不足：

1 gc current block congested

2 gc cr block congested

3 gc current grant congested

4 gc cr grant congested

1  gc current block congested

  當一個例項需要當前模式的塊時，它向主控例項發生請求。請求者透過快取融合獲得該塊；但是，由於“叢集組服務”(GCS)的工作量過重而使塊傳遞過延遲。與我們前面看到的一樣，如果IPC佇列中的任何訊息傳輸或塊傳輸在被LMS程式選的等待時間超過1毫秒，就會看到擁塞等待。

    這一事件並不意味著在塊級別存在任何併發或爭用。但是，它的確表明GCS的負載過多，參與其工作的後臺程式需要更多的CPU時間，如果擁有塊的例項上缺少CPU資源，那麼可能會導致這一問題。新增更多的LMS程式有時也可以幫助克服這一情景。

2  gc cr block congested

這個事件和gc current block congested事件相同，但在這種情況下，發出請求的例項已經請求了CR模式的塊。

Wait events for Oracle RAC include the following categories:

Block-Related Wait Events

Message-Related Wait Events

Contention-Related Wait Events

Load-Related Wait Events

Block-Related Wait Events

The main wait events for block-related waits are:

1 gc current block 2-way

2 gc current block 3-way

3 gc cr block 2-way

4 gc cr block 3-way

The block-related wait event statistics indicate that a block was received as either the result of a 2-way or a 3-way message, that is, the block was sent from either the resource master requiring 1 message and 1 transfer, or was forwarded to a third node from which it was sent, requiring 2 messages and 1 block transfer.

Message-Related Wait Events

The main wait events for message-related waits are:

1 gc current grant 2-way

2 gc cr grant 2-way

The message-related wait event statistics indicate that no block was received because it was not cached in any instance. Instead a global grant was given, enabling the requesting instance to read the block from disk or modify it.

If the time consumed by these events is high, then it may be assumed that the frequently used SQL causes a lot of disk I/O (in the event of the cr grant) or that the workload inserts a lot of data and needs to find and format new blocks frequently (in the event of the current grant).

Contention-Related Wait Events

The main wait events for contention-related waits are:

1 gc current block busy

2 gc cr block busy

3 gc buffer busy acquire/release

The contention-related wait event statistics indicate that a block was received which was pinned by a session on another node, was deferred because a change had not yet been flushed to disk or because of high concurrency, and therefore could not be shipped immediately. A buffer may also be busy locally when a session has already initiated a cache fusion operation and is waiting for its completion when another session on the same node is trying to read or modify the same data. High service times for blocks exchanged in the global cache may exacerbate the contention, which can be caused by frequent concurrent read and write accesses to the same data.

The gc current block busy and gc cr block busy wait events indicate that the local instance that is making the request did not immediately receive a current or consistent read block. The term  busy in these events' names indicates that the sending of the block was delayed on a remote instance. For example, a block cannot be shipped immediately if Oracle Database has not yet written the redo for the block's changes to a log file.

In comparison to block busy wait events, a gc buffer busy event indicates that Oracle Database cannot immediately grant access to data that is stored in the local buffer cache. This is because a global operation on the buffer is pending and the operation has not yet completed. In other words, the buffer is busy and all other processes that are attempting to access the local buffer must wait to complete.

The existence of gc buffer busy events also means that there is block contention that is resulting in multiple requests for access to the local block. Oracle Database must queue these requests. The length of time that Oracle Database needs to process the queue depends on the remaining service time for the block. The service time is affected by the processing time that any network latency adds, the processing time on the remote and local instances, and the length of the wait queue.

The average wait time and the total wait time should be considered when being alerted to performance issues where these particular waits have a high impact. Usually, either interconnect or load issues or SQL execution against a large shared working set can be found to be the root cause.

Load-Related Wait Events

The main wait events for load-related waits are:

1 gc current block congested

2 gc cr block congested

The load-related wait events indicate that a delay in processing has occurred in the GCS, which is usually caused by high load, CPU saturation and would have to be solved by additional CPUs, load-balancing, off loading processing to different times or a new cluster node.For the events mentioned, the wait time encompasses the entire round trip from the time a session starts to wait after initiating a block request until the block arrives.

http://blog.chinaunix.net/uid-17069315-id-5682409.html

 

    歡迎關注我的微信公眾號"IT小Chen"，共同學習，共同成長！！！