如何進(jìn)行Oracle常見(jiàn)的等待事件分析

如何進(jìn)行Oracle常見(jiàn)的等待事件分析，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

1.Library cache pin

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

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

--Handle address: 被加載的對(duì)象的地址。

--Lock address： 鎖的地址。

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

--Namespace： 被加載對(duì)象在 v$db_object_cache 視圖中 namespace 名稱(chēng)。

2.Log file parallel write

后臺(tái)進(jìn)程 LGWR 負(fù)責(zé)將 log buffer 當(dāng)中的數(shù)據(jù)寫(xiě)到 REDO 文件中，以重用 log buffer 的數(shù)據(jù)。 如果每個(gè) REDO LOG 組里面有 2 個(gè)以上的成員，那么 LGWR 進(jìn)程會(huì)并行地將 REDO 信息寫(xiě)入這些文件中。

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

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

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

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

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

3.Log buffer space

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

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

-- 增加 redo buffer 的大小。

-- 提升磁盤(pán)的 I/O 性能

4.Log file sequential read

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

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

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

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

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

5.Log file single write

這個(gè)等待事件發(fā)生在更新 redo log 文件的文件頭時(shí)，當(dāng)為日志組增加新的日志成員時(shí)或者 redo log 的 sequence 號(hào)改變時(shí)，LGWR 都會(huì)更新 redo log 文件頭信息。

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

--Log#： 寫(xiě)入的 redo log 組的編號(hào)。

--Block#：寫(xiě)入的數(shù)據(jù)塊號(hào)。

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

6.Log file switch(archiving needed)

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

這個(gè)等待事件沒(méi)有參數(shù)。

7.Log file switch(checkpoint incomplete)

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

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

--Active: 這個(gè)日志上面保護(hù)的信息還沒(méi)有完成 checkpoint。

--Inactive： 這個(gè)日志上面保護(hù)的信息已完成 checkpoint。

--Current： 當(dāng)前的日志。

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

這個(gè)等待事件沒(méi)有參數(shù)。

8.Log file sync

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

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

-- 高提交頻率

解決方法是簡(jiǎn)單的消除不必要的提交，事務(wù)是工作單元。工作單元應(yīng)該是全部成功或全部失敗。

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

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

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

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

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

過(guò)小的日志緩沖區(qū)，還會(huì)導(dǎo)致 log buffer space 等待

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

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

Buffer#: redo buffer 中需要被寫(xiě)入到磁盤(pán)中的 buffer。

9.SQL*Net break/reset to client

當(dāng)出現(xiàn)這個(gè)等待事件時(shí)，說(shuō)明服務(wù)器端在給客戶端發(fā)送一個(gè)斷開(kāi)連接或者重置連接的請(qǐng)求，正在等待客戶的響應(yīng)，通常的原因是服務(wù)器到客戶端的網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的。

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

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

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

10.SQL*Net break/reset to dblink

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

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

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

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

11.SQL*Net message from client

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

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

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

--#bytes: 服務(wù)器端接收到的來(lái)自客戶端消息的字節(jié)數(shù)。

12.SQL*Net message from dblink

這個(gè)等待事件和 SQL*Net message from client 相同，不過(guò)它表示的是數(shù)據(jù)庫(kù)通過(guò) dblink 訪問(wèn)另一個(gè)數(shù)據(jù)庫(kù)時(shí)，他們之間會(huì)建立一個(gè)會(huì)話，這個(gè)等待事件發(fā)生在這個(gè)會(huì)話之間的通信過(guò)程中。

這個(gè)等待事件也是一個(gè)空閑等待事件。

這個(gè)事件包含兩個(gè)參數(shù)：

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

--#bytes: 服務(wù)器端通過(guò) dblink 收到的來(lái)自另一個(gè)服務(wù)器端消息的字節(jié)數(shù)。

13.SQL*Net message to client

這個(gè)等待事件發(fā)生在服務(wù)器端向客戶端發(fā)送消息的時(shí)候。 當(dāng)服務(wù)器端向客戶端發(fā)送消息產(chǎn)生等待時(shí)，可能的原因是用戶端太繁忙，無(wú)法及時(shí)接收服務(wù)器端送來(lái)的消息，也可能是網(wǎng)絡(luò)問(wèn)題導(dǎo)致消息無(wú)法從服務(wù)器端發(fā)送到客戶端。 

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

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

--#bytes: 服務(wù)器端向客戶端發(fā)送消息的字節(jié)數(shù)。

14.SQL*Net message to dblink

這個(gè)等待事件和 SQL*Net message to client 相同，不過(guò)是發(fā)生在數(shù)據(jù)庫(kù)服務(wù)器和服務(wù)器之間的等待事件，產(chǎn)生這個(gè)等待的原因可能是遠(yuǎn)程服務(wù)器繁忙，而無(wú)法及時(shí)接收發(fā)送過(guò)來(lái)的消息，也可能是服務(wù)器之間網(wǎng)絡(luò)問(wèn)題導(dǎo)致消息無(wú)法發(fā)送過(guò)來(lái)。

這個(gè)等待時(shí)間包含兩個(gè)參數(shù)：

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

--#bytes: 服務(wù)器端通過(guò) dblink 發(fā)送給另一個(gè)服務(wù)器消息的字節(jié)數(shù)。

15.SQL*Net more data from client

服務(wù)器端等待用戶發(fā)出更多的數(shù)據(jù)以便完成操作，比如一個(gè)大的 SQL 文本，導(dǎo)致一個(gè) SQL*Net 數(shù)據(jù)包無(wú)法完成傳輸，這樣服務(wù)器端會(huì)等待客戶端把整個(gè) SQL 文本發(fā)過(guò)來(lái)在做處理，這時(shí)候就會(huì)產(chǎn)生一個(gè) SQL*Net more data from client 等待事件。

這個(gè)等待時(shí)間包含兩個(gè)參數(shù)：

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

--#bytes: 服務(wù)器端從客戶端接收到消息的字節(jié)數(shù)。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。