ORACLE 常見等待事件

一． 等待事件的相關知識

1.1 等待事件主要能夠分爲兩類，即空閒(IDLE)等待事件和非空閒(NON-IDLE)等待事件。
1). 空閒等待事件指ORACLE正等待某種工做，在診斷和優化數據庫的時候，不用過多注意這部分事件。
2). 非空閒等待事件專門針對ORACLE的活動，指數據庫任務或應用運行過程當中發生的等待，這些等待事件 是在調整數據庫的時候須要關注與研究的。

 
在Oracle 10g中的等待事件有872個，11g中等待事件1116個。 咱們能夠經過v$event_name 視圖來查看等待事件的相關信息。

1.2 查看v$event_name視圖的字段結構
SQL> desc v$event_name;
  名稱                  是否爲空? 類型
 ----------------------------------------- -------- ---------------
 EVENT#                NUMBER
  EVENT_ID              NUMBER
  NAME                VARCHAR2(64)
  PARAMETER1          VARCHAR2(64)
  PARAMETER2          VARCHAR2(64)
  PARAMETER3          VARCHAR2(64)
  WAIT_CLASS_ID        NUMBER
  WAIT_CLASS#          NUMBER
  WAIT_CLASS          VARCHAR2(64)

 1.3 查看等待事件總數
11gr2:
 SQL> select count(*) from v$event_name;
  COUNT(*)
 ----------
      1116
 10gr2 rac:
 sys@ORCL> select count(*) from v$event_name;

  COUNT(*)
 ----------
        889
 10gr2:
 SQL> select count(*) from v$event_name;

  COUNT(*)
 ----------
        874

  
 1.4 查看等待事件分類狀況
/* Formatted on 6/27/2011 12:54:45 PM (QP5 v5.114.809.3010) */
  SELECT  wait_class#,
            wait_class_id,
            wait_class,
            COUNT ( * ) AS "count"
    FROM  v$event_name
 GROUP BY  wait_class#, wait_class_id, wait_class
 ORDER BY  wait_class#;

 WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS                count
 ----------- ------------- -------------------- ----------
          0    1893977003 Other                      717
          1    4217450380 Application                  17
          2    3290255840 Configuration                24
          3    4166625743 Administrative              54
          4    3875070507 Concurrency                  32
          5    3386400367 Commit                        2
          6    2723168908 Idle                        94
          7    2000153315 Network                      35
          8    1740759767 User I/O                    45
          9    4108307767 System I/O                  30
          10    2396326234 Scheduler                    7
          11    3871361733 Cluster                      50
          12    644977587 Queueing                      9

  
 1.5 相關的幾個視圖
V$SESSION：表明數據庫活動的開始，視爲源起。
V$SESSION_WAIT：視圖用以實時記錄活動SESSION的等待狀況，是當前信息。
V$SESSION_WAIT_HISTORY：是對V$SESSION_WAIT的簡單加強，記錄活動SESSION的最近10次等待。
V$SQLTEXT：當數據庫出現瓶頸時，一般能夠從V$SESSION_WAIT找到那些正在等待資源的SESSION，
 經過SESSION的SID，聯合V$SESSION和V$SQLTEXT視圖就能夠捕獲這些SESSION正在執行的SQL語句。
V$ACTIVE_SESSION_HISTORY:是ASH的核心，用以記錄活動SESSION的歷史等待信息，每秒採樣一次，這部份內容記錄在內存中，指望值是記錄一個小時的內容。
WRH#_ACTIVE_SESSION_HISTORY: 是V$ACTIVE_SESSION_HISTORY在AWR的存儲地。
V$ACTIVE_SESSION_HISTORY中 的信息會被按期(每小時一次)的刷新到負載庫中，並缺省保留一個星期
 用於分析。
DBA_HIST_ACTIVE_SESS_HISTORY:視圖是WRH#_ACTIVE_SESSION_HISTORY視圖和其餘幾個視圖的聯合展示，一般經過這個視圖進行歷史數據的訪問。
V$SYSTEM_EVENT: 因爲V$SESSION記錄的是動態信息，和SESSION的生命週期相關，而並不記錄歷史信
 息，因此ORACLE提供視圖V$SYSTEM_EVENT來記錄數據庫自啓動以來全部等待事件的彙總信息。經過這個視圖，用戶能夠迅速得到數據庫運行的整體概況。

 二． 33個常見的等待事件
1. Buffer busy waits
從本質上講，這個等待事件的產生僅說明了一個會話在等待一個Buffer（數據塊），可是致使這個現象的緣由卻有不少種。
 常見的兩種是：
·          當一個會話試圖修改一個數據塊，但這個數據塊正在被另外一個會話修改時。
·          當一個會話須要讀取一個數據塊，但這個數據塊正在被另外一個會話讀取到內存中時。

Oracle 操做的最小單位是塊（Block），即便你要修改一條記錄，也須要對這條記錄所在的這個數據塊作操做。 當你對這個數據塊作修改時，其餘的會話將被阻止對這個數據塊上的數據作修改（即便其餘用戶修改的不是當前用戶修改的數據），可是能夠以一致性的方式讀取這個數據塊（from undo）。當前的用戶修改完這個數據塊後，將會當即釋放掉加在這個數據塊上的排他鎖，這樣另外一個會話就能夠繼續修改它。修改操做是一個很是短暫的時間，這種加鎖的機制咱們叫Latch。

 當一個會話修改一個數據塊時，是按照如下步驟來完成的：
·          以排他的方式得到這個數據塊（Latch）
·          修改這個數據塊。
·          釋放Latch。

Buffer busy waits等待事件常見於數據庫中存在熱塊的時候，當多個用戶頻繁地讀取或者修改一樣的數據塊時，這個等待事件就會產生。 若是等待的時間很長，咱們在AWR或者statspack 報告中就能夠看到。

 這個等待事件有三個參數。查看有幾個參數咱們能夠用如下SQL:
 /* Formatted on 6/27/2011 1:06:09 PM (QP5 v5.114.809.3010) */
 SELECT  name,
          parameter1,
          parameter2,
          parameter3
  FROM  v$event_name
  WHERE  name = 'buffer busy waits';
 NAME                  PARAMETER1  PARAMETER2  PARAMETER3
 --------------------  ----------  ----------  ----------
 buffer busy waits    file#        block#      class#

  
在下面的示例中，查詢的方法和這個同樣，因此其餘事件對參數的查詢將不作過多的說明。

File#: 等待訪問數據塊所在的文件id號。
Blocks： 等待訪問的數據塊號。
ID： 在10g以前，這個值表示一個等待時間的緣由，10g以後則表示等待事件的類別。

2. Buffer latch
內存中數據塊的存放位置是記錄在一個hash列表（cache buffer chains）當中的。當一個會話須要訪問某個數據塊時，它首先要搜索這個hash 列表，從列表中得到數據塊的地址，而後經過這個地址去訪問須要的數據塊，這個列表Oracle會使用一個latch來保護它的完整性。 當一個會話須要訪問這個列表時，須要獲取一個Latch，只有這樣，才能保證這個列表在這個會話的瀏覽當中不會發生變化。

 產生buffer latch的等待事件的主要緣由是：
·          Buffer chains太長，致使會話搜索這個列表花費的時間太長，使其餘的會話處於等待狀態。
·          一樣的數據塊被頻繁訪問，就是咱們一般說的熱快問題。

 產生buffer chains太長，咱們可使用多個buffer pool的方式來建立更多的buffer chains，或者使用參數DB_BLOCK_LRU_LATCHES來增長latch的數量，以便於更多的會話能夠得到latch，這兩種方法能夠同時使用。

 這個等待事件有兩個參數：
Latch addr： 會話申請的latch在SGA中的虛擬地址。
 經過如下的SQL語句能夠根據這個地址找到它對應的Latch名稱：
/* Formatted on 6/27/2011 1:12:48 PM (QP5 v5.114.809.3010) */
 select * from v$latch a,v$latchname b where
 addr=latch addr -- 這裏的latch addr 是你從等待事件中看到的值 
and a.latch#=b.latch#;

 chain#： buffer chains hash 列表中的索引值，當這個參數的值等於s 0xfffffff時，說明當前的會話正在等待一個LRU latch。

3. Control file parallel write
當數據庫中有多個控制文件的拷貝時，Oracle 須要保證信息同步地寫到各個控制文件當中，這是一個並行的物理操做過程，由於稱爲控制文件並行寫，當發生這樣的操做時，就會產生control file parallel write等待事件。
 控制文件頻繁寫入的緣由不少，好比：
·          日誌���換太過頻繁，致使控制文件信息相應地須要頻繁更新。
·          系統I/O 出現瓶頸，致使全部I/O出現等待。

 當系統出現日誌切換過於頻繁的情形時，能夠考慮適當地增大日誌文件的大小來下降日誌切換頻率。
 當系統出現大量的control file parallel write 等待事件時，能夠經過好比下降控制文件的拷貝數量，將控制文件的拷貝存放在不一樣的物理磁盤上的方式來緩解I/O 爭用。

 這個等待事件包含三個參數：
Files： Oracle 要寫入的控制文件個數。
Blocks： 寫入控制文件的數據塊數目。
Requests： 寫入控制請求的I/O 次數。

4. Control file sequential read
當數據庫須要讀取控制文件上的信息時，會出現這個等待事件，由於控制文件的信息是順序寫的，因此讀取的時候也是順序的，所以稱爲控制文件順序讀，它常常發生在如下狀況：
 備份控制文件
RAC 環境下不一樣實例之間控制文件的信息共享
 讀取控制文件的文件頭信息
 讀取控制文件其餘信息

 這個等待事件有三個參數：
File#： 要讀取信息的控制文件的文件號。
Block#： 讀取控制文件信息的起始數據塊號。
Blocks： 須要讀取的控制文件數據塊數目。

 
5. Db file parallel read
這是一個很容易引發誤導的等待事件，實際上這個等待事件和並行操做（好比並行查詢，並行DML）沒有關係。 這個事件發生在數據庫恢復的時候，當有一些數據塊須要恢復的時候，Oracle會以並行的方式把他們從數據文件中讀入到內存中進行恢復操做。

 這個等待事件包含三個參數：
Files： 操做須要讀取的文件個數。
Blocks： 操做須要讀取的數據塊個數。
Requests： 操做須要執行的I/O次數。

 
6. Db file parallel write
這是一個後臺等待事件，它一樣和用戶的並行操做沒有關係，它是由後臺進程DBWR產生的，當後臺進程DBWR向磁盤上寫入髒數據時，會發生這個等待。

DBWR會批量地將髒數據並行地寫入到磁盤上相應的數據文件中，在這個批次做業完成以前，DBWR將出現這個等待事件。若是僅僅是這一個等待事件，對用戶的操做並無太大的影響，當伴隨着出現free buffer waits等待事件時，說明此時內存中可用的空間不足，這時候會影響到用戶的操做，好比影響到用戶將髒數據塊讀入到內存中。

 當出現db file parallel write等待事件時，能夠經過啓用操做系統的異步I/O的方式來緩解這個等待。當使用異步I/O時，DBWR再也不須要一直等到全部數據塊所有寫入到磁盤上，它只須要等到這個數據寫入到一個百分比以後，就能夠繼續進行後續的操做。

 這個等待事件有兩個參數：
Requests： 操做須要執行的I/O次數。
Timeouts： 等待的超時時間。

 
7. Db file scattered read
這個等待事件在實際生產庫中常常能夠看到，這是一個用戶操做引發的等待事件，當用戶發出每次I/O須要讀取多個數據塊這樣的SQL 操做時，會產生這個等待事件，最多見的兩種狀況是全表掃描（FTS： Full Table Scan）和索引快速掃描（IFFS： index fast full scan）。

 這個名稱中的scattered( 分散)，可能會致使不少人認爲它是以scattered 的方式來讀取數據塊的，其實偏偏相反，當發生這種等待事件時，SQL的操做都是順序地讀取數據塊的，好比FTS或者IFFS方式（若是忽略須要讀取的數據塊已經存在內存中的狀況）。

 這裏的scattered指的是讀取的數據塊在內存中的存放方式，他們被讀取到內存中後，是以分散的方式存在在內存中，而不是連續的。

 這個等待事件有三個參數：
File#： 要讀取的數據塊所在數據文件的文件號。
Block#： 要讀取的起始數據塊號。
Blocks： 須要讀取的數據塊數目。

 
8. Db file sequential read
這個等待事件在實際生產庫也很常見，當Oracle 須要每次I/O只讀取單個數據塊這樣的操做時，會產生這個等待事件。最多見的狀況有索引的訪問（除IFFS外的方式），回滾操做，以ROWID的方式訪問表中的數據，重建控制文件，對文件頭作DUMP等。

 這裏的sequential也並不是指的是Oracle 按順序的方式來訪問數據，和db file scattered read同樣，它指的是讀取的數據塊在內存中是以連續的方式存放的。

 這個等待事件有三個參數：
File#： 要讀取的數據塊鎖在數據文件的文件號。
Block#： 要讀取的起始數據塊號。
Blocks： 要讀取的數據塊數目（這裏應該等於1）。

 
9. Db file single write
這個等待事件一般只發生在一種狀況下，就是Oracle 更新數據文件頭信息時（好比發生Checkpoint）。

 當這個等待事件很明顯時，須要考慮是否是數據庫中的數據文件數量太大，致使Oracle 須要花較長的時間來作全部文件頭的更新操做（checkpoint）。

 這個等待事件有三個參數：
File#: 須要更新的數據塊所在的數據文件的文件號。
Block#： 須要更新的數據塊號。
Blocks： 須要更新的數據塊數目（一般來講應該等於1）。

 
10. Direct path read
這個等待事件發生在會話將數據塊直接讀取到PGA當中而不是SGA中的狀況，這些被讀取的數據一般是這個會話私有的數據，因此不須要放到SGA做爲共享數據，由於這樣作沒有意義。這些數據一般是來自於臨時段上的數據，好比一個會話中SQL的排序數據，並行執行過程當中間產生的數據，以及Hash Join，merge join產生的排序數據，由於這些數據只對當前的會話的SQL操做有意義，因此不須要放到SGA當中。

 當發生direct path read等待事件時，意味着磁盤上有大量的臨時數據產生，好比排序，並行執行等操做。或者意味着PGA中空閒空間不足。

 這個等待事件有三個參數：
Descriptor address:  一個指針，指向當前會話正在等待的一個direct read I/O。
First dba: descriptor address 中最舊的一個I/O數據塊地址。
Block cnt: descriptor address上下文中涉及的有效的buffer 數量。

 
11. Direct path write
這個等待事件和direct path read 正好相反，是會話將一些數據從PGA中直接寫入到磁盤文件上，而不通過SGA。

 這種狀況一般發生在：
 使用臨時表空間排序（內存不足）
 數據的直接加載（使用append方式加載數據）
 並行DML操做。

 這個等待事件有三個參數：
Descriptor address: 一個指針，指向當前會話正在等待的一個direct I/O.
 First dba: descriptor address 中最舊的一個I/O數據塊地址。
Block cnt: descriptor address 上下文中涉及的有效地 buffer 數量。

 12. Enqueue
 Enqueue 這個詞實際上是lock 的另外一種描述語。

 當咱們在AWR 報告中發現長時間的enqueue 等待事件時，說明數據庫中出現了阻塞和等待，能夠關聯AWR報告中的enqueue activity部分來肯定是哪種鎖定出現了長時間等待。

 這個等待事件有2個參數：
Name： enqueue 的名稱和類型。
Mode： enqueue的模式。

 可使用以下SQL 查看當前會話等待的enqueue名稱和類型：
/* Formatted on 6/27/2011 1:31:48 PM (QP5 v5.114.809.3010) */
 SELECT  CHR (TO_CHAR (BITAND (p1, -16777216)) / 16777215)
          || CHR (TO_CHAR (BITAND (p1, 16711680)) / 65535)
            "Lock",
          TO_CHAR (BITAND (p1, 65535)) "Mode"
  FROM  v$session_wait
  WHERE  event = 'enqueue';

 13. Free buffer waits
當一個會話將數據塊從磁盤讀到內存中時，它須要到內存中找到空閒的內存空間來存放這些數據塊，當內存中沒有空閒的空間時，就會產生這個等待；除此以外，還有一種狀況就是會話在作一致性讀時，須要構造數據塊在某個時刻的前映像（image），此時須要申請內存來存放這些新構造的數據塊，若是內存中沒法找到這樣的內存塊，也會發生這個等待事件。

 當數據庫中出現比較嚴重的free buffer waits等待事件時，可能的緣由是：
 （1）data buffer 過小，致使空閒空間不夠
 （2）內存中的髒數據太多，DBWR沒法及時將這些髒數據寫到磁盤中以釋放空間

 這個等待事件包含2個參數：
File#： 須要讀取的數據塊所在的數據文件的文件號。
Block#： 須要讀取的數據塊塊號。

 
14. Latch free
在10g以前的版本里，latch free 等待事件表明了全部的latch等待，在10g之後，一些經常使用的latch事件已經被獨立了出來：
11gr2:
 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: MQL Tracking Latch
 latch: PX hash array latch
 latch: Undo Hint Latch
 latch: WCR: processes HT
 latch: WCR: sync
 latch: cache buffer handles
 latch: cache buffers chains
 latch: cache buffers lru chain
 latch: call allocation
 latch: change notification client cache latch
 latch: checkpoint queue latch
 latch: enqueue hash chains
 latch: gc element
 latch: gcs resource hash
 latch: ges resource hash list
 latch: lob segment dispenser latch
 latch: lob segment hash table latch
 latch: lob segment query latch
 latch: messages
 latch: object queue header operation
 latch: parallel query alloc buffer
 latch: redo allocation
 latch: redo copy
 latch: redo writing
 latch: row cache objects
 latch: session allocation
 latch: shared pool
 latch: undo global data
 latch: virtual circuit queues
已選擇33行。

10gr2 rac:
 sys@ORCL> 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
 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
 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 等待事件出現。

 這個等待事件有三個參數：
Address: 會話等待的latch 地址。
Number： latch號，經過這個號，能夠從v$latchname 視圖中找到這個latch 的相關的信息。
SQL> select * from v$latchname where latch#=number;
 Tries: 會話嘗試獲取Latch 的次數。

 
15. Library cache lock
這個等待事件發生在不一樣用戶在共享中因爲併發操做同一個數據庫對象致使的資源爭用的時候，好比當一個用戶正在對一個表作DDL 操做時，其餘的用戶若是要訪問這張表，就會發生library cache lock等待事件，它要一直等到DDL操做完成後，才能繼續操做。

 這個事件包含四個參數：
Handle address: 被加載的對象的地址。
Lock address： 鎖的地址。
Mode： 被加載對象的數據片斷。
Namespace： 被加載對象在v$db_object_cache 視圖中namespace名稱。

10gr2 rac:
 sys@ORCL> select name from v$event_name where name like 'library%' order by 1;

 NAME
 --------------------------------------------------
 library cache load lock
 library cache lock
 library cache pin
 library cache revalidation
 library cache shutdown

  
 16. Library cache pin
這個等待事件和library cache lock 同樣是發生在共享池中併發操做引發的事件。一般來說，若是Oracle 要對一些PL/SQL 或者視圖這樣的對象作從新編譯，須要將這些對象pin到共享池中。若是此時這個對象被其餘的用戶特有，就會產生一個library cache pin的等待。

 這個等待事件也包含四個參數：
Handle address: 被加載的對象的地址。
Lock address： 鎖的地址。
Mode： 被加載對象的數據片斷。
Namespace： 被加載對象在v$db_object_cache 視圖中namespace名稱。

 
17. Log file parallel write
後臺進程LGWR 負責將log buffer當中的數據寫到REDO 文件中，以重用log buffer的數據。若是每一個REDO LOG組裏面有2個以上的成員，那麼LGWR進程會並行地將REDO 信息寫入這些文件中。

 若是數據庫中出現這個等待事件的瓶頸，主要的緣由多是磁盤I/O性能不夠或者REDO 文件的分佈致使了I/O爭用，好比同一個組的REDO 成員文件放在相同的磁盤上。

 這個等待事件有三個參數：
Files： 操做須要寫入的文件個數。
Blocks： 操做須要寫入的數據塊個數。
Requests：操做須要執行的I/O次數。

 
18. Log buffer space
當log buffer 中沒有可用空間來存放新產生的redo log數據時，就會發生log buffer space等待事件。若是數據庫中新產生的redo log的數量大於LGWR 寫入到磁盤中的redo log 數量，必須等待LGWR 完成寫入磁盤的操做，LGWR必須確保redo log寫到磁盤成功以後，才能在redo buffer當中重用這部分信息。

 若是數據庫中出現大量的log buffer space等待事件，能夠考慮以下方法：
 （1）增長redo buffer的大小。
 （2）提高磁盤的I/O性能

19. Log file sequential read
這個等待事件一般發生在對redo log信息進行讀取時，好比在線redo 的歸檔操做，ARCH進程須要讀取redo log的信息，因爲redo log的信息是順序寫入的，因此在讀取時也是按照順序的方式來讀取的。

 這個等待事件包含三個參數：
Log#： 發生等待時讀取的redo log的sequence號。
Block#： 讀取的數據塊號。
Blocks： 讀取的數據塊個數。

 
20. Log file single write
這個等待事件發生在更新redo log文件的文件頭時，當爲日誌組增長新的日誌成員時或者redo log的sequence號改變時，LGWR 都會更新redo log文件頭信息。

 這個等待事件包含三個參數：
Log#： 寫入的redo log組的編號。
Block#：寫入的數據塊號。
Blocks：寫入的數據塊個數。

 
21. Log file switch(archiving needed)
在歸檔模式下，這個等待事件發生在在線日誌切換（log file switch）時，須要切換的在線日誌尚未被歸檔進程（ARCH）歸檔完畢的時候。 當在線日誌文件切換到下一個日誌時，須要確保下一個日誌文件已經被歸檔進程歸檔完畢，不然不容許覆蓋那個在線日誌信息（不然會致使歸檔日誌信息不完整）。

 出現這樣的等待事件一般是因爲某種緣由致使ARCH 進程死掉，好比ARCH進程嘗試向目的地寫入一個歸檔文件，可是沒有成功（介質失效或者其餘緣由），這時ARCH進程就會死掉。 若是發生這種狀況，在數據庫的alert log文件中能夠找到相關的錯誤信息。

 這個等待事件沒有參數。

 
22. Log file switch(checkpoint incomplete)
當一個在線日誌切換到下一個在線日誌時，必須保證要切換到的在線日誌上的記錄的信息（好比一些髒數據塊產生的redo log）被寫到磁盤上（checkpoint），這樣作的緣由是，若是一個在線日誌文件的信息被覆蓋，而依賴這些redo 信息作恢復的數據塊還沒有被寫到磁盤上（checkpoint），此時系統down掉的話，Oracle將沒有辦法進行實例恢復。

 在v$log 視圖裏記錄了在線日誌的狀態。一般來講，在線日誌有三種狀態。
Active: 這個日誌上面保護的信息尚未完成checkpoint。
Inactive： 這個日誌上面保護的信息已完成checkpoint。
Current： 當前的日誌。

Oracle 在作實例恢復時，會使用狀態爲current和Active的日誌進行實例恢復。

 若是系統中出現大量的log file switch（checkpoint incomplete）等待事件，緣由多是日誌文件過小或者日誌組太少，因此解決的方法是，增長日誌文件的大小或者增長日誌組的數量。

 這個等待事件沒有參數。

23. Log file sync
這是一個用戶會話行爲致使的等待事件，當一個會話發出一個commit命令時，LGWR進程會將這個事務產生的redo log從log buffer裏面寫到磁盤上，以確保用戶提交的信息被安全地記錄到數據庫中。

 會話發出的commit指令後，須要等待LGWR將這個事務產生的redo 成功寫入到磁盤以後，才能夠繼續進行後續的操做，這個等待事件就叫做log file sync。

 當系統中出現大量的log file sync等待事件時，應該檢查數據庫中是否有用戶在作頻繁的提交操做。

 這種等待事件一般發生在OLTP系統上。OLTP 系統中存在不少小的事務，若是這些事務頻繁被提交，可能引發大量的log file sync的等待事件。

 這個等待事件包含一個參數：
Buffer#: redo buffer 中須要被寫入到磁盤中的buffer。

 
24. SQL*Net break/reset to client
當出現這個等待事件時，說明服務器端在給客戶端發送一個斷開鏈接或者重置鏈接的請求，正在等待客戶的響應，一般的緣由是服務器到客戶端的網絡不穩定致使的。

 這個等待事件包含兩個參數：
Driver id: 服務器和客戶端鏈接使用的協議信息。
Break？：零表示服務端向客戶端發送一個重置（reset）信息，非零表示服務器端向客戶端發送一個斷開（break）消息。

 
25. SQL*Net break/reset to dblink
這個等待事件和SQL*Net break/reset to client 相同。不過它表示的是數據庫經過dblink訪問另外一臺數據庫時，他們之間創建起一個會話，這個等待事件發生在這個會話之間的通訊過程當中，一樣若是出現這個等待事件，須要檢查兩臺數據庫之間的通訊問題。

 這個等待事件有兩個參數：
Driver id: 服務器和客戶端鏈接使用的協議信息。
Break？：零表示服務端向客戶端發送一個重置（reset）信息，非零表示服務器端向客戶端發送一個斷開（break）消息。

26. SQL*Net message from client
這個等待事件基本上是最多見的一個等待事件。當一個會話創建成功後，客戶端會向服務器端發送請求，服務器端處理完客戶端請求後，將結果返回給客戶端，並繼續等待客戶端的請求，這時候會產生SQL*Net message from client 等待事件。

 很顯然，這是一個空閒等待，若是客戶端再也不向服務器端發送請求，服務器端將一直處於這個等待事件狀態。

 這個等待事件包含兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端接收到的來自客戶端消息的字節數。

 
27． SQL*Net message from dblink
這個等待事件和SQL*Net message from client相同，不過它表示的是數據庫經過dblink 訪問另外一個數據庫時，他們之間會創建一個會話，這個等待事件發生在這個會話之間的通訊過程當中。

 這個等待事件也是一個空閒等待事件。

 這個事件包含兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端經過dblink 收到的來自另外一個服務器端消息的字節數。

28. SQL*Net message to client
這個等待事件發生在服務器端向客戶端發送消息的時候。當服務器端向客戶端發送消息產生等待時，可能的緣由是用戶端太繁忙，沒法及時接收服務器端送來的消息，也多是網絡問題致使消息沒法從服務器端發送到客戶端。

 這個等待事件有兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端向客戶端發送消息的字節數。

 
29. SQL*Net message to dblink
這個等待事件和SQL*Net message to client 相同，不過是發生在數據庫服務器和服務器之間的等待事件，產生這個等待的緣由多是遠程服務器繁忙，而沒法及時接收發送過來的消息，也多是服務器之間網絡問題致使消息沒法發送過來。

 這個等待時間包含兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端經過dblink發送給另外一個服務器消息的字節數。

 
30. SQL*Net more data from client
服務器端等待用戶發出更多的數據以便完成操做，好比一個大的SQL文本，致使一個SQL*Net 數據包沒法完成傳輸，這樣服務器端會等待客戶端把整個SQL 文本發過來在作處理，這時候就會產生一個SQL*Net more data from client 等待事件。

 這個等待時間包含兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端從客戶端接收到消息的字節數。

 
31. SQL*Net more data from dblink
在一個分佈式事務中，SQL 分佈在不一樣的數據庫中執行，遠程數據庫執行完畢後將結果經過dblink返給發出SQL的數據庫，在等待數據從其餘數據庫中經過dblink傳回的過程當中，若是數據在遠程數據庫上處理時間好久，或者有大量的結果集須要返回，或者網絡性能問題都會產生SQL*Net more data from dblink 等待事件，它的意思是本地數據庫須要等到全部的數據從遠程處理完畢經過dblink傳回後，才能夠在本機繼續執行操做。

 這個等待時間包含兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端經過dblink發送給另外一個服務器消息的字節數。

 
32. SQL*Net more data to client
當服務器端有太多的數據須要發給客戶端時，可能會產生SQL*Net more data to client等待事件，也可能因爲網絡問題致使服務器沒法及時地將信息或者處理結果發送給客戶端，一樣會產生這個等待。

 這個等待時間包含兩個參數：
Driver id: 服務器端和客戶端鏈接使用的協議信息。
#bytes: 服務器端向客戶端發送消息的字節數。

 
33. SQL*Net more data to dblink
這個等待事件和SQL*Net more data to client 等待時間基本相同，只不過等待發生在分佈式事務中，即本地數據庫須要將更多的數據經過dblink發送給遠程數據庫。因爲發送的數據太多或者網絡性能問題，就會出現SQL*Net more data to dblink等待事件。

 這個等待時間包含兩個參數：Driver id: 服務器端和客戶端鏈接使用的協議信息。#bytes: 服務器端經過dblink發送給另外一個服務器消息的字節數。