1. Buffer busy waits
從本質上講，這個等待事件的產生僅說明了一個會話在等待一個Buffer（資料塊），但是導致這個現象的原因卻有很多種，常見的兩種是：
當一個會話試圖修改一個數據塊，但這個資料塊正在被另一個會話修改時。
當一個會話需要讀取一個數據塊，但這個資料塊正在被另一個會話讀取到記憶體中時。

Oracle 操作的最小單位是塊（Block），即使你要修改一條記錄，也需要對這條記錄所在的這個資料塊做操作。 當你對這個資料塊做修改時，其他的會話將被阻止對這個資料塊上的資料做修改（即使其他使用者修改的不是當前使用者修改的資料），但是可以以一致性的方式讀取這個資料塊（from undo）。當前的使用者修改完這個資料塊後，將會立即釋放掉加在這個資料塊上的排他鎖，這樣另一個會話就可以繼續修改它。修改操作是一個非常短暫的時間，這種加鎖的機制我們叫Latch（閂）。

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

Buffer busy waits等待事件常見於資料庫中存在熱塊的時候，當多個使用者頻繁地讀取或者修改同樣的資料塊時，這個等待事件就會產生。 如果等待的時間很長，我們在AWR或者statspack 報告中就可以看到。

這個等待事件有三個引數。檢視有幾個引數我們可以用以下SQL:

 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名稱：

   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名稱和型別：

 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:
 [email protected]> 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:

 [email protected]> 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文字，導致一個SQLNet 資料包無法完成傳輸，這樣伺服器端會等待客戶端把整個SQL 文字發過來在做處理，這時候就會產生一個SQLNet 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
這個等待事件和SQLNet more data to client 等待時間基本相同，只不過等待發生在分散式事務中，即本地資料庫需要將更多的資料通過dblink傳送給遠端資料庫。由於傳送的資料太多或者網路效能問題，就會出現SQLNet more data to dblink等待事件。

這個等待時間包含兩個引數：
Driver id: 伺服器端和客戶端連線使用的協議資訊。
#bytes: 伺服器端通過dblink傳送給另一個伺服器訊息的位元組數。

備註：
等待事件分兩類，即空閒(IDLE)等待事件和非空閒(NON-IDLE)等待事件。

1. 空閒等待事件指ORACLE正等待某種工作，在診斷和優化資料庫的時候，不用過多注意這部分事件。
2. 非空閒等待事件專門針對ORACLE的活動，指資料庫任務或應用執行過程中發生的等待，NON-IDLE等待才是需要運維人員細細研究的地方。