将夜猫腻小说,欢乐颂小说结局是什么,耳根

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

必看干貨|Oracle常見的等待事件說(shuō)明（下）

16.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 名稱。

17.Log file parallel write

后臺(tái)進(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ù)庫(kù)中出現(xiàn)這個(gè)等待事件的瓶頸，主要的原因可能是磁盤 I/O 性能不夠或者 REDO 文件的分布導(dǎo)致了 I/O 爭(zhēng)用，比如同一個(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 中沒有可用空間來(lái)存放新產(chǎn)生的 redo log 數(shù)據(jù)時(shí)，就會(huì)發(fā)生 log buffer space 等待事件。如果數(shù)據(jù)庫(kù)中新產(chǎn)生的 redo log 的數(shù)量大于 LGWR 寫入到磁盤中的 redo log 數(shù)量，必須等待 LGWR 完成寫入磁盤的操作，LGWR 必須確保 redo log 寫到磁盤成功之后，才能在 redo buffer 當(dāng)中重用這部分信息。

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

-- 增加 redo buffer 的大小。

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

19.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ù)。

20.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#：寫入的 redo log 組的編號(hào)。

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

--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ù)庫(kù)的 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)。通常來(lái)說(shuō)，在線日志有三種狀態(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ù)庫(kù)中。會(huì)話發(fā)出的 commit 指令后，需要等待 LGWR 將這個(gè)事務(wù)產(chǎn)生的 redo 成功寫入到磁盤之后，才可以繼續(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)寫入的數(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)寫入，從而減少 log file sync 的等待時(shí)間.

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

過(guò)小的日志緩沖區(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í)，說(shuō)明服務(wù)器端在給客戶端發(fā)送一個(gè)斷開連接或者重置連接的請(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è)斷開（break）消息。

25.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è)斷開（break）消息。

26.SQL*Net message from client

這個(gè)等待事件基本上是最常見的一個(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ù)：