Oracle中常見的33個等待事件小結

在Oracle g中的等待事件有個g中等待事件個 我們可以通過v$event_name 視圖來查看等待事件的相關信息  

　　一． 等待事件的相關知識

等待事件主要可以分為兩類即空閒(IDLE)等待事件和非空閒(NONIDLE)等待事件
) 空閒等待事件指ORACLE正等待某種工作在診斷和優化數據庫的時候不用過多注意這部分事件
) 非空閒等待事件專門針對ORACLE的活動指數據庫任務或應用運行過程中發生的等待這些等待事件 是在調整數據庫的時候需要關注與研究的

 
在Oracle g中的等待事件有個g中等待事件個 我們可以通過v$event_name 視圖來查看等待事件的相關信息

查看v$event_name視圖的字段結構
SQL> desc v$event_name;
 名稱                   是否為空? 類型
 
 EVENT#                NUMBER
 EVENT_ID              NUMBER
 NAME                 VARCHAR()
 PARAMETER          VARCHAR()
 PARAMETER          VARCHAR()
 PARAMETER          VARCHAR()
 WAIT_CLASS_ID        NUMBER
 WAIT_CLASS#          NUMBER
 WAIT_CLASS           VARCHAR()

查看等待事件總數
gr:
SQL> select count(*) from v$event_name;
  COUNT(*)

     
gr rac:
sys@ORCL> select count(*) from v$event_name;

  COUNT(*)

      
gr:
SQL> select count(*) from v$event_name;

  COUNT(*)

      

 
查看等待事件分類情況
/* Formatted on // :: PM (QP v) */
  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

              Other                      
              Application                 
              Configuration               
              Administrative              
              Concurrency                 
              Commit                       
              Idle                        
              Network                     
              User I/O                    
              System I/O                  
             Scheduler                    
             Cluster                     
              Queueing                     

 
相關的幾個視圖
V$SESSION代表數據庫活動的開始視為源起
V$SESSION_WAIT視圖用以實時記錄活動SESSION的等待情況是當前信息
V$SESSION_WAIT_HISTORY是對V$SESSION_WAIT的簡單增強記錄活動SESSION的最近次等待
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來記錄數據庫自啟動以來所有等待事件的匯總信息通過這個視圖用戶可以迅速獲得數據庫運行的總體概況

 
二． 個常見的等待事件

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

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

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

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

這個等待事件有三個參數查看有幾個參數我們可以用以下SQL:
/* Formatted on // :: PM (QP v) */
SELECT   name
         parameter
         parameter
         parameter
  FROM   v$event_name
 WHERE   name = buffer busy waits;
NAME                  PARAMETER   PARAMETER  PARAMETER
      
buffer busy waits     file#        block#      class#

 
在下面的示例中查詢的方法和這個一樣所以其他事件對參數的查詢將不做過多的說明

File#: 等待訪問數據塊所在的文件id號
Blocks 等待訪問的數據塊號
ID 在g之前這個值表示一個等待時間的原因g之後則表示等待事件的類別

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 // :: PM (QP v) */
select * from v$latch av$latchname b where
addr=latch addr 這裡的latch addr 是你從等待事件中看到的值
and alatch#=blatch#;

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

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 次數

Control file sequential read
當數據庫需要讀取控制文件上的信息時會出現這個等待事件因為控制文件的信息是順序寫的所以讀取的時候也是順序的因此稱為控制文件順序讀它經常發生在以下情況
備份控制文件
RAC 環境下不同實例之間控制文件的信息共享
讀取控制文件的文件頭信息
讀取控制文件其他信息

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

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

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

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

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

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

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

 
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 需要讀取的數據塊數目

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

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

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

 
Db file single write
這個等待事件通常只發生在一種情況下就是Oracle 更新數據文件頭信息時（比如發生Checkpoint）

當這個等待事件很明顯時需要考慮是不是數據庫中的數據文件數量太大導致Oracle 需要花較長的時間來做所有文件頭的更新操作（checkpoint）

這個等待事件有三個參數
File#: 需要更新的數據塊所在的數據文件的文件號
Block# 需要更新的數據塊號
Blocks 需要更新的數據塊數目（通常來說應該等於）

 
Direct path read
這 個等待事件發生在會話將數據塊直接讀取到PGA當中而不是SGA中的情況這些被讀取的數據通常是這個會話私有的數據所以不需要放到SGA作為共享數 據因為這樣做沒有意義這些數據通常是來自於臨時段上的數據比如一個會話中SQL的排序數據並行執行過程中間產生的數據以及Hash Joinmerge join產生的排序數據因為這些數據只對當前的會話的SQL操作有意義所以不需要放到SGA當中

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

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

 
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 數量

 
Enqueue
Enqueue 這個詞其實是lock 的另一種描述語

當我們在AWR 報告中發現長時間的enqueue 等待事件時說明數據庫中出現了阻塞和等待可以關聯AWR報告中的enqueue activity部分來確定是哪一種鎖定出現了長時間等待

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

可以使用如下SQL 查看當前會話等待的enqueue名稱和類型
/* Formatted on // :: PM (QP v) */
SELECT   CHR (TO_CHAR (BITAND (p )) / )
         || CHR (TO_CHAR (BITAND (p )) / )
            "Lock"
         TO_CHAR (BITAND (p )) "Mode"
  FROM   v$session_wait
 WHERE   event = enqueue;

Oracle 的enqueue 包含以下模式

模式代碼
解釋

Null (NULL)

RowS(SS)

RowX(SX)

Share(S)

S/RowX(SSX)

Exclusive(X)

Oracle的enqueue 有如下類型
Enqueue 縮寫
縮寫解釋
BL
Buffer Cache management
BR
Backup/Restore
CF
Controlfile transaction
CI
Crossinstance Call Invocation
CU
Bind Enqueue
DF
Datafile
DL
Direct Loader Index Creation
DM
Database Mount
DR
Distributed Recovery Process
DX
Dirstributed Transaction
FP
File Object
FS
File Set
HW
Highwater Lock
IN
Instance Number
IR
Instance Recovery
IS
Instance State
IV
Library Cache Invalidation
JI
Enqueue used during AJV snapshot refresh
JQ
Job Queue
KK
Redo Log “Kick”
KO
Multiple Object Checkpoint
L[Ap]
Library Cache Lock
LS
Log start or switch
MM
Mount Definition
MR
Media recovery
N[AZ]
Library Cache bin
PE
Alter system set parameter =value
PF
Password file
PI
Parallel slaves
PR
Process startup

Parallel slave synchronization
Q[AZ]
Row Cache
RO
Object Reuse
RT
Redo Thread
RW
Row Wait
SC
System Commit Number
SM
SMON

Sequence Number
SQ
Sequence Number Enqueue
SR
Synchronized replication

Sort segment
ST
Space management transaction
SV
Sequence number Value
TA
Transaction recovery
TC
Thread Checkpoint
TE
Extend Table
TM
DML enqueue
TO
Temporary Table Object Enqueue
TS
Temporary Segement(also TableSpace)
TT
Temporary Table
TX
Transaction
UL
Userdefined Locks
UN
User name
US
Undo segment Serialization
WL
Being Written Redo Log
XA
Instance Attribute Log
XI   
Instance Registration Lock

 
關於enqueue 可以參考如下的連接
Wait Events Enqueue Waits


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

當數據庫中出現比較嚴重的free buffer waits等待事件時可能的原因是
（）data buffer 太小導致空閒空間不夠
（）內存中的髒數據太多DBWR無法及時將這些髒數據寫到磁盤中以釋放空間

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

 
Latch free
在g之前的版本裡latch free 等待事件代表了所有的latch等待在g以後一些常用的latch事件已經被獨立了出來
gr:
SQL> select name from v$event_name where name like latch% order by ;
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
已選擇行

gr rac:
sys@ORCL> select name from v$event_name where name like latch% order by ;

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

rows selected

 
所以latch free 等待事件在g以後的版本中並不常見而是以具體的Latch 等待事件出現

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

 
Library cache lock
這個等待事件發生在不同用戶在共享中由於並發操作同一個數據庫對象導致的資源爭用的時候比如當一個用戶正在對一個表做DDL 操作時其他的用戶如果要訪問這張表就會發生library cache lock等待事件它要一直等到DDL操作完成後才能繼續操作

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

gr rac:
sys@ORCL> select name from v$event_name where name like library% order by ;

NAME

library cache load lock
library cache lock
library cache pin
library cache revalidation
library cache shutdown

 
Library cache pin
這 個等待事件和library cache lock 一樣是發生在共享池中並發操作引起的事件通常來講如果Oracle 要對一些PL/SQL 或者視圖這樣的對象做重新編譯需要將這些對象pin到共享池中如果此時這個對象被其他的用戶特有就會產生一個library cache pin的等待

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

 
Log file parallel write
後台進程LGWR 負責將log buffer當中的數據寫到REDO 文件中以重用log buffer的數據如果每個REDO LOG組裡面有個以上的成員那麼LGWR進程會並行地將REDO 信息寫入這些文件中

如果數據庫中出現這個等待事件的瓶頸主要的原因可能是磁盤I/O性能不夠或者REDO 文件的分布導致了I/O爭用比如同一個組的REDO 成員文件放在相同的磁盤上

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

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

如果數據庫中出現大量的log buffer space等待事件可以考慮如下方法
（）增加redo buffer的大小
（）提升磁盤的I/O性能

Log file sequential read
這個等待事件通常發生在對redo log信息進行讀取時比如在線redo 的歸檔操作ARCH進程需要讀取redo log的信息由於redo log的信息是順序寫入的所以在讀取時也是按照順序的方式來讀取的

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

 
Log file single write
這個等待事件發生在更新redo log文件的文件頭時當為日志組增加新的日志成員時或者redo log的sequence號改變時LGWR 都會更新redo log文件頭信息

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

 
Log file switch(archiving needed)
在 歸檔模式下這個等待事件發生在在線日志切換（log file switch）時需要切換的在線日志還沒有被歸檔進程（ARCH）歸檔完畢的時候 當在線日志文件切換到下一個日志時需要確保下一個日志文件已經被歸檔進程歸檔完畢否則不允許覆蓋那個在線日志信息（否則會導致歸檔日志信息不完整）

出現這樣的等待事件通常是由於某種原因導致ARCH 進程死掉比如ARCH進程嘗試向目的地寫入一個歸檔文件但是沒有成功（介質失效或者其他原因）這時ARCH進程就會死掉 如果發生這種情況在數據庫的alert log文件中可以找到相關的錯誤信息

這個等待事件沒有參數

 
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）等待事件原因可能是日志文件太小或者日志組太少所以解決的方法是增加日志文件的大小或者增加日志組的數量

這個等待事件沒有參數

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

 
SQL*Net break/reset to client
當出現這個等待事件時說明服務器端在給客戶端發送一個斷開連接或者重置連接的請求正在等待客戶的響應通常的原因是服務器到客戶端的網絡不穩定導致的

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

 
SQL*Net break/reset to dblink
這 個等待事件和SQL*Net break/reset to client 相同不過它表示的是數據庫通過dblink訪問另一台數據庫時他們之間建立起一個會話這個等待事件發生在這個會話之間的通信過程中同樣如果出現這 個等待事件需要檢查兩台數據庫之間的通信問題

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

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

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

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

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

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

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

SQL*Net message to client
這個等待事件發生在服務器端向客戶端發送消息的時候當服務器端向客戶端發送消息產生等待時可能的原因是用戶端太繁忙無法及時接收服務器端送來的消息也可能是網絡問題導致消息無法從服務器端發送到客戶端

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

 
SQL*Net message to dblink
這個等待事件和SQL*Net message to client 相同不過是發生在數據庫服務器和服務器之間的等待事件產生這個等待的原因可能是遠程服務器繁忙而無法及時接收發送過來的消息也可能是服務器之間網絡問題導致消息無法發送過來

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

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

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

 
SQL*Net more data from dblink
在 一個分布式事務中SQL 分布在不同的數據庫中執行遠程數據庫執行完畢後將結果通過dblink返給發出SQL的數據庫在等待數據從其他數據庫中通過dblink傳回的過程 中如果數據在遠程數據庫上處理時間很久或者有大量的結果集需要返回或者網絡性能問題都會產生SQL*Net more data from dblink 等待事件它的意思是本地數據庫需要等到所有的數據從遠程處理完畢通過dblink傳回後才可以在本機繼續執行操作

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

 
SQL*Net more data to client
當服務器端有太多的數據需要發給客戶端時可能會產生SQL*Net more data to client等待事件也可能由於網絡問題導致服務器無法及時地將信息或者處理結果發送給客戶端同樣會產生這個等待

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

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

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

From:http://tw.wingwit.com/Article/program/Oracle/201311/19100.html