[[212099]]

16.Library cache pin

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

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

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

--Lock address： 鎖的地址。

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

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

17.Log file parallel write

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

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

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

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

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

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

18.Log buffer space

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

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

-- 增加 redo buffer 的大小。

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

19.Log file sequential read

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

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

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

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

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

20.Log file single write

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

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

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

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

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

21.Log file switch(archiving needed)

在歸檔模式下，這個(gè)等待事件發(fā)生在在線日志切換（log file switch）時(shí)，需要切換的在線日志還沒有被歸檔進(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)程嘗試向目的地寫入一個(gè)歸檔文件，但是沒有成功（介質(zhì)失效或者其他原因），這時(shí) ARCH 進(jìn)程就會(huì)死掉。 如果發(fā)生這種情況，在數(shù)據(jù)庫的 alert log 文件中可以找到相關(guān)的錯(cuò)誤信息。

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

22.Log file switch(checkpoint incomplete)

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

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

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

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

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

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

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

23.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 里面寫到磁盤上，以確保用戶提交的信息被安全地記錄到數(shù)據(jù)庫中。會(huì)話發(fā)出的 commit 指令后，需要等待 LGWR 將這個(gè)事務(wù)產(chǎn)生的 redo 成功寫入到磁盤之后，才可以繼續(xù)進(jìn)行后續(xù)的操作，這個(gè)等待事件就叫作 log file sync。

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

-- 高提交頻率

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

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

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

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

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

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

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

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

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

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

24.SQL*Net break/reset to client

當(dāng)出現(xiàn)這個(gè)等待事件時(shí)，說明服務(wù)器端在給客戶端發(fā)送一個(gè)斷開連接或者重置連接的請求，正在等待客戶的響應(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è)斷開（break）消息。

25.SQL*Net break/reset to dblink

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

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

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

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

26.SQL*Net message from client

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

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

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

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

27.SQL*Net message from dblink

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

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

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

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

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

28.SQL*Net message to client

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

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

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

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

29.SQL*Net message to dblink

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

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

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

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

30.SQL*Net more data from client

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

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

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

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