[每天進步一點點]常見的等待事件：
1、buffer busy waits:這個等待事件說明了一個會話在等待一個buffer cache裡面的資料塊。引起該等待事件的原因一般是資料庫中存在熱塊，當多個使用者頻繁地讀取或者修改同樣的資料塊時，這個等待事件就會產生，如果等待的時間很長，我們在awr或者statspack報告中可以看到；

2、buffer latch：在data buffer catch中，有一個hash列表叫cache buffer chains，用來記錄data buffer catch 裡髒資料塊的地址的。當一個會話訪問cache buffer chains時，需要獲取一個latch鎖，只有這樣，才能保證這個列表在這個會話的瀏覽中不會發生改變。產生buffer latch的等待事件的主要原因：a,buffer chains太長，搜尋時間長，導致其他會話等待，解決辦法就是使用多個buffer pool的方式建立多個buffer chains或者使用引數db_block_lru_latches增加latch數量，以便於獲得更多的latch，這兩種方法可以同時使用。b、有熱塊導致的buffer latch等待事件；

3、control file parallel write 當資料庫中有多個控制檔案的複製時，oracle需要保證資訊同步地寫到各個控制檔案當中，這是一個並行的物理操作過程，因此稱為控制檔案並行寫，當發生這樣的操作時，就會產生contril file parallel write等待事件。引起該事件的原因有a、日誌切換太過頻繁，導致控制文件資訊需要頻繁地更新，解決辦法就是適當的增大日誌檔案的大小來降低日誌切換頻率；b、系統的I/O出現瓶頸，解決辦法就是降低控制檔案的複製數量，將控制文件的複製存放在不同的物理磁碟上的方式來緩解I/O爭用。

4、control file sequential read 因為控制檔案的資訊是順序寫入的，所以讀取的時候也是順序讀取的，因此該事件稱為控制檔案順序讀，它發生在資料庫需要讀取控制檔案上的資訊時，有以下幾種情況：a、備份控制檔案；b、RAC環境下不同例項之間控制檔案的資訊共享；c、讀取控制檔案的檔案頭資訊；D、讀取控制檔案其他資訊；

5、db file parallel read 這是一個引起誤導的等待事件，實際上這個等待事件和並行操作（比如並行查詢，並行DML）沒有關係。這個事件發生在資料庫恢復的時候，當有一些資料塊需要恢復的時候，oracle會以並行的方式把他們從資料檔案中讀入到記憶體進行恢復操作。

6、db file parallel write這個事件同樣和使用者並行操作沒有關係，它是由後臺程式dbwr產生的，當dbwr將髒資料塊向磁碟寫入的時，就會發生這個等待。當僅僅是這一個等待時，對使用者的操作是沒有太大的影響，但是伴隨著出現free buffer waits等待事件時，說明此時記憶體中可用的空間不足了，會影響使用者的操作，比如影響使用者將資料塊讀入記憶體中。解決辦法就是啟用作業系統的非同步I/O來緩解這個等待。因為使用非同步I/O，dbwr就不需要一直等待所有的資料塊全部寫入到磁碟

上，它只需要等到資料寫入到一個百分比後，就可以繼續後面的操作了。

7、db file scattered(發散) read 當使用者發出每次I/O需要讀取多個資料塊這樣的SQL操作時，就會產生這個等待事件，最常見的兩種情況是全表掃描（FTS full table sacn）和索引快速掃描（IFFS INDEX FAST FULL SCAN）。其實這裡的

scattered指的是讀取的資料塊在記憶體中的存放方式，他們被讀取到記憶體中後，是以分散的方式存放在記憶體中的，而不是連續的。但發生這種等待事件是，SQL的操作都是順序地讀取資料塊的，比如FTS或IFFS。

8、db file sequential read 這個等待事件發生在使用者每次I/O只讀取單個資料塊的操作時發生的。最常見的情況有除IFFS以外的索引訪問、回滾操作，以rowid 的方式訪問表中的資料，重建控制檔案，對檔案頭做DUMP。這裡的sequential（順序）也並非指的是oracle按照順序地方式來訪問資料，它指的是讀取的資料塊在記憶體中是以連續的方式存放的。

9、db file single write 這個等待事件只發生在oracle更新資料檔案頭資訊時，比如發生checkpoint；當這個等待事件很明顯時，原因可能是資料庫中的資料檔案數量太大導致；

10、direct path read 這個等待事件發生在會話將資料塊直接讀取到PGA（私有會話）當中而不是SGA（共享資料）中時，這些資料通常來自臨時段上的資料，比如排序，因為這些資料只對當前會話的SQL操作有意義，不需要放在SGA中。當發生direct path read等待事件時，意味著磁碟上有大量的臨時資料產生，比如排序、並行執行等操作，或者意味著PGA空間不足。

11、direct path write 是指將PGA的資料直接寫入到磁碟上，而不經過SGA。這種情況發生在，使用臨時表空間排序（記憶體排序不足）資料的直接載入（使用append方式載入資料）或並行DML操作。

12、enqueue 這個詞其實是lock的另一個描述與，我們要把他理解為lock，如果再awr出現這個等待事件，說明資料庫中出現了阻塞和等待，可關聯AWR中的enqueue activity 來確定哪一種鎖出現了長時間等待。

13、free buffer waits 出現這種情況的原因是：a、data buffer cache的空間太小；b、記憶體中的髒資料太多，DBWR無法及時將這些髒資料寫到磁碟中以釋放空間。

14、latch free

SQL> select name from v$event_name where name like 'latch%' order by 1;

NAME

----------------------------------------------------------------

latch activity

latch free

latch: Change Notification Hash table latch

latch: In memory undo latch

latch: KCL gc element parent latch

latch: MQL Tracking Latch

latch: Undo Hint Latch

latch: cache buffer handles

latch: cache buffers chains

latch: cache buffers lru chain

latch: checkpoint queue latch

NAME

----------------------------------------------------------------

latch: enqueue hash chains

latch: gcs resource hash

latch: ges resource hash list

latch: library cache

latch: library cache lock

latch: library cache pin

latch: messages

latch: object queue header heap

latch: object queue header operation

latch: parallel query alloc buffer

latch: redo allocation

NAME

----------------------------------------------------------------

latch: redo copy

latch: redo writing

latch: row cache objects

latch: session allocation

latch: shared pool

latch: undo global data

latch: virtual circuit queues

29 rows selected.

所以latch free 等待事件在10G中並不常見，而是以具體的latch等待事件出現的。

15、library cache lock 這個等待事件發生在不同使用者在共享池中由於並發操作同一個資料庫物件導致的資源爭用的時候，比方當一個使用者在對一個表做DDL操作時，其他使用者如要訪問這張表，就會發生library cache lock等待事件，它一

直等到DDL操作完畢後才繼續操作。

16、library cache pin 這個等待事件也是發生在共享池中併發引起的等待事件，通常來說，如果ORACLE需要對一些PL/SQL或檢視這樣的物件做重新編譯，需要將這些物件pin到共享池中。如果這個物件被其他使用者持有，就會產生一個

library cache pin的等待。

17、log file parallel write 後臺程式lgwr將log buffer 寫到redo檔案，當redo log 組裡有兩個以上成員時，那麼lgwr就會並行的將redo寫到這些檔案中。出現這個等待，主要原因是磁碟I/O能力不厚或者REDO成員檔案的分佈在相同的磁

盤上導致的I/O爭用。

18、log buffer space 表示log buffer當中沒有空間來儲存新產生的redo log資料了，解決辦法是增加redo buffer 的大小或者提高磁碟的I/O效能。

19、log file sequential read 這個等待事件發生在對redo log 資訊進行讀取時，比如線上redo的歸檔操作，ARCH程式讀取redo log資訊，由於redo log的資訊是順序寫入的，所以在讀取時也是順序讀取的。

20、log file single write 這個等待事件發生在更新redo log檔案的文件頭時，當為日誌組增加新的日誌成員時或者redo log 的sequence號改變時，lgwr都會更新redo log的檔案頭資訊。

21、log file swich (archiving needed)這個等待事件發生在線上日誌切換時，需要切換到線上日誌還沒有被歸檔程式歸檔完畢的時候。當出現這個等待事件通常都是由於某種原因導致的ARCH程式死掉，沒法歸檔了，這個會在altert日誌

中看到報警資訊。

22、log file switch (checkpint incomplete) 當一個線上日誌切換到下一個線上日誌時，必須保證要切換到的線上日誌上記錄的髒資料別寫到磁碟上（checkpoint），如果系統中出現大量這個等待事件，原因可能是日誌檔案太小或

者日誌組太少（我認為應該是切換太快，導致redo對應的髒資料還沒有來得及寫盤），所以解決的方式是增減日誌檔案的大小或者增加日誌組的數量。

23、log file sync 當會話發出commit指令後，需要等待lgwr將這個事務產生的redo成功寫入到磁碟之後，才可以進行後續的操作，這個等待事件叫Log file sync，當系統出現大量的這個等待事件時，應檢查是否有使用者頻繁的做提交的操作。這種等待事件通常發生在oltp系統中。

24、SQL*Net break/reset to client 當出現這個等待事件，說明服務端在給客戶端傳送一個斷開連線或者重置連線的請求，正在等待客戶端的相應，通常的原因是伺服器到客戶端的網路不穩定導致的。

25、SQL*Net break/reset to dblink 這個等待事件和SQL*Net break/reset to client相同，不過它表示的是資料庫透過DBLINK訪問另一臺資料庫時，如果出現這個等待事件，需要檢查兩臺資料庫之間的通訊問題。

26、SQL*Net message from client 空閒等待，說明伺服器很閒

27、SQL*Net messagefrom dblink 這個等待事件和SQL*Net message from client相同，不過它表示的是資料庫透過DBLINK訪問另一臺資料庫時，他們之間會建立一個會話，這個等待事件是一個空閒事件。

28、SQL*Net message to client 這個等待事件發生在伺服器想客戶端發送訊息的時候發生的等待，可能原因是客戶端太忙，無法及時接收伺服器的訊息，也可能是網路問題導致的訊息無法從伺服器送到客戶端。

29、SQL*Net message to dblink 這個等待事件和SQL*Net message to client相同，不過是發生在資料庫和遠端伺服器之間的事件，產生這個等待的原因可能是遠端伺服器繁忙，無法及時接收到發來的訊息，或者網路的原因導致的訊息無法傳送過來。

30、SQL*Net more data from client 伺服器等待使用者端發出更多的資料以便完成操作，比如一個大的SQL檔案，導致一個SQL*NET資料包無法完成傳輸，這樣伺服器會等待客戶端把整個SQL文字發過來再處理

31、SQL*NET more data from dblink 在一個分散式事務中，SQL分佈在不同的資料庫中執行，遠端資料庫執行完畢後將結果透過DBLINK返回給發出SQL資料庫，在等待資料從其他資料塊中透過DBLINK傳回的過程中，如果資料在遠端資料庫行處理的時間太久，或者有大量的結果集需要返回，或者網路問題都會導致該事件的產生，他的意思是本地資料庫需要等到所有的資料從遠端處理完畢透過DBLINK傳回後才可以在本季繼續操作。

32 SQL*Net more data to client 當伺服器有太多的資料需要傳送給客戶端時可能會產生該事件，也可能是網路原因導致的伺服器無法及時地將資訊或處理結果傳送給客戶端。

33、SQL*Net more data to dblink 這個等待事件和SQL*Net more data

to client 等待事件基本相同，只不過等待發生在分散式事務中，即本地資料庫需將更多的資料透過DBLINK傳送給遠端資料庫，或者由於網路效能問題。

oracle等待事件

相關文章