如何進行Oracle常見的等待事件分析

發布時間：2021-11-29 11:16:41 來源：億速云閱讀：147 作者：柒染欄目：數據庫

如何進行Oracle常見的等待事件分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

1.Library cache pin

這個等待事件和 library cache lock 一樣是發生在共享池中并發操作引起的事件。通常來講，如果 Oracle 要對一些 PL/SQL 或者視圖這樣的對象做重新編譯，需要將這些對象 pin 到共享池中。如果此時這個對象被其他的用戶特有，就會產生一個 library cache pin 的等待。

這個等待事件也包含四個參數：

--Handle address: 被加載的對象的地址。

--Lock address：鎖的地址。

--Mode：被加載對象的數據片段。

--Namespace：被加載對象在 v$db_object_cache 視圖中 namespace 名稱。

2.Log file parallel write

后臺進程 LGWR 負責將 log buffer 當中的數據寫到 REDO 文件中，以重用 log buffer 的數據。如果每個 REDO LOG 組里面有 2 個以上的成員，那么 LGWR 進程會并行地將 REDO 信息寫入這些文件中。

如果數據庫中出現這個等待事件的瓶頸，主要的原因可能是磁盤 I/O 性能不夠或者 REDO 文件的分布導致了 I/O 爭用，比如同一個組的 REDO 成員文件放在相同的磁盤上。

這個等待事件有三個參數：

--Files：操作需要寫入的文件個數。

--Blocks：操作需要寫入的數據塊個數。

--Requests：操作需要執行的 I/O 次數。

3.Log buffer space

當 log buffer 中沒有可用空間來存放新產生的 redo log 數據時，就會發生 log buffer space 等待事件。如果數據庫中新產生的 redo log 的數量大于 LGWR 寫入到磁盤中的 redo log 數量，必須等待 LGWR 完成寫入磁盤的操作，LGWR 必須確保 redo log 寫到磁盤成功之后，才能在 redo buffer 當中重用這部分信息。

如果數據庫中出現大量的 log buffer space 等待事件，可以考慮如下方法：

-- 增加 redo buffer 的大小。

-- 提升磁盤的 I/O 性能

4.Log file sequential read

這個等待事件通常發生在對 redo log 信息進行讀取時，比如在線 redo 的歸檔操作，ARCH 進程需要讀取 redo log 的信息，由于 redo log 的信息是順序寫入的，所以在讀取時也是按照順序的方式來讀取的。

這個等待事件包含三個參數：

--Log#：發生等待時讀取的 redo log 的 sequence 號。

--Block#：讀取的數據塊號。

--Blocks：讀取的數據塊個數。

5.Log file single write

這個等待事件發生在更新 redo log 文件的文件頭時，當為日志組增加新的日志成員時或者 redo log 的 sequence 號改變時，LGWR 都會更新 redo log 文件頭信息。

這個等待事件包含三個參數：

--Log#：寫入的 redo log 組的編號。

--Block#：寫入的數據塊號。

--Blocks：寫入的數據塊個數。

6.Log file switch(archiving needed)

在歸檔模式下，這個等待事件發生在在線日志切換（log file switch）時，需要切換的在線日志還沒有被歸檔進程（ARCH）歸檔完畢的時候。當在線日志文件切換到下一個日志時，需要確保下一個日志文件已經被歸檔進程歸檔完畢，否則不允許覆蓋那個在線日志信息（否則會導致歸檔日志信息不完整）。出現這樣的等待事件通常是由于某種原因導致 ARCH 進程死掉，比如 ARCH 進程嘗試向目的地寫入一個歸檔文件，但是沒有成功（介質失效或者其他原因），這時 ARCH 進程就會死掉。如果發生這種情況，在數據庫的 alert log 文件中可以找到相關的錯誤信息。

這個等待事件沒有參數。

7.Log file switch(checkpoint incomplete)

當一個在線日志切換到下一個在線日志時，必須保證要切換到的在線日志上的記錄的信息（比如一些臟數據塊產生的 redo log）被寫到磁盤上（checkpoint），這樣做的原因是，如果一個在線日志文件的信息被覆蓋，而依賴這些 redo 信息做恢復的數據塊尚未被寫到磁盤上（checkpoint），此時系統 down 掉的話，Oracle 將沒有辦法進行實例恢復。

在 v$log 視圖里記錄了在線日志的狀態。通常來說，在線日志有三種狀態。

--Active: 這個日志上面保護的信息還沒有完成 checkpoint。

--Inactive：這個日志上面保護的信息已完成 checkpoint。

--Current：當前的日志。

如果系統中出現大量的 log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志組太少，所以解決的方法是，增加日志文件的大小或者增加日志組的數量。

這個等待事件沒有參數。

8.Log file sync

這是一個用戶會話行為導致的等待事件，當一個會話發出一個 commit 命令時，LGWR 進程會將這個事務產生的 redo log 從 log buffer 里面寫到磁盤上，以確保用戶提交的信息被安全地記錄到數據庫中。會話發出的 commit 指令后，需要等待 LGWR 將這個事務產生的 redo 成功寫入到磁盤之后，才可以繼續進行后續的操作，這個等待事件就叫作 log file sync。

以下幾種情況，可能產生這個等待：

-- 高提交頻率

解決方法是簡單的消除不必要的提交，事務是工作單元。工作單元應該是全部成功或全部失敗。

-- 緩慢的 I/O 子系統

較高的 IO 吞吐良可以改善 log file sync 和 log file parallel write 事件的平均等待時間。頻繁的提交會弄亂數據庫布局和 IO 子系統。解決辦法是將日志文件放裸設備上或綁定在 RAID 0 或 RAID 0+1 中，而不是綁定在 RAID 5 中。

-- 過大的日志緩沖區

過大的日志緩沖區也可能延長 log file sync 等待。大型的日志緩沖區減少后臺寫入的數量，允許 LGWR 變得懶惰，并導致更多的重做條目堆積在日志緩沖區中。同時可以調整參數_LOG_IO_SIZE 參數，其默認值是 LOG_BUFFER 的 1/3 或 1MB，取兩者之中較小的值。換句話說，你可以具有較大的日志緩沖區，但較小的_LOG_IO_SIZE 將增加后臺寫入，從而減少 log file sync 的等待時間.

-- 過小的日志緩沖區

過小的日志緩沖區，還會導致 log buffer space 等待

-- 日志組多少與日志大小不合適

這個等待事件包含一個參數：

Buffer#: redo buffer 中需要被寫入到磁盤中的 buffer。

9.SQL*Net break/reset to client

當出現這個等待事件時，說明服務器端在給客戶端發送一個斷開連接或者重置連接的請求，正在等待客戶的響應，通常的原因是服務器到客戶端的網絡不穩定導致的。

這個等待事件包含兩個參數：

--Driver id: 服務器和客戶端連接使用的協議信息。

--Breaks：零表示服務端向客戶端發送一個重置（reset）信息，非零表示服務器端向客戶端發送一個斷開（break）消息。

10.SQL*Net break/reset to dblink

這個等待事件和 SQL*Net break/reset to client 相同。不過它表示的是數據庫通過 dblink 訪問另一臺數據庫時，他們之間建立起一個會話，這個等待事件發生在這個會話之間的通信過程中，同樣如果出現這個等待事件，需要檢查兩臺數據庫之間的通信問題。

這個等待事件有兩個參數：

--Driver id: 服務器和客戶端連接使用的協議信息。

--Breaks：零表示服務端向客戶端發送一個重置（reset）信息，非零表示服務器端向客戶端發送一個斷開（break）消息。

11.SQL*Net message from client

這個等待事件基本上是最常見的一個等待事件。當一個會話建立成功后，客戶端會向服務器端發送請求，服務器端處理完客戶端請求后，將結果返回給客戶端，并繼續等待客戶端的請求，這時候會產生 SQL*Net message from client 等待事件。很顯然，這是一個空閑等待，如果客戶端不再向服務器端發送請求，服務器端將一直處于這個等待事件狀態。

這個等待事件包含兩個參數：