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

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

成都創(chuàng)新互聯(lián)2013年至今，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目成都做網(wǎng)站、成都網(wǎng)站設計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元鯉城做網(wǎng)站,已為上家服務,為鯉城各地企業(yè)和個人服務,聯(lián)系電話:13518219792

1.Library cache pin

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

這個等待事件也包含四個參數(shù)：

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

--Lock address：鎖的地址。

--Mode：被加載對象的數(shù)據(jù)片段。

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

2.Log file parallel write

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

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

這個等待事件有三個參數(shù)：

--Files：操作需要寫入的文件個數(shù)。

--Blocks：操作需要寫入的數(shù)據(jù)塊個數(shù)。

--Requests：操作需要執(zhí)行的 I/O 次數(shù)。

3.Log buffer space

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

如果數(shù)據(jù)庫中出現(xiàn)大量的 log buffer space 等待事件，可以考慮如下方法：

-- 增加 redo buffer 的大小。

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

4.Log file sequential read

這個等待事件通常發(fā)生在對 redo log 信息進行讀取時，比如在線 redo 的歸檔操作，ARCH 進程需要讀取 redo log 的信息，由于 redo log 的信息是順序?qū)懭氲模栽谧x取時也是按照順序的方式來讀取的。

這個等待事件包含三個參數(shù)：

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

--Block#：讀取的數(shù)據(jù)塊號。

--Blocks：讀取的數(shù)據(jù)塊個數(shù)。

5.Log file single write

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

這個等待事件包含三個參數(shù)：

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

--Block#：寫入的數(shù)據(jù)塊號。

--Blocks：寫入的數(shù)據(jù)塊個數(shù)。

6.Log file switch(archiving needed)

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

這個等待事件沒有參數(shù)。

7.Log file switch(checkpoint incomplete)

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

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

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

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

--Current：當前的日志。

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

這個等待事件沒有參數(shù)。

8.Log file sync

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

以下幾種情況，可能產(chǎn)生這個等待：

-- 高提交頻率

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

-- 緩慢的 I/O 子系統(tǒng)

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

-- 過大的日志緩沖區(qū)

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

-- 過小的日志緩沖區(qū)

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

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

這個等待事件包含一個參數(shù)：

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

9.SQL*Net break/reset to client

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

這個等待事件包含兩個參數(shù)：

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

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

10.SQL*Net break/reset to dblink

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

這個等待事件有兩個參數(shù)：

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

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

11.SQL*Net message from client

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

這個等待事件包含兩個參數(shù)：