當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

ORACLE 等待事件

發布時間：2025/3/17 编程问答 38 豆豆

生活随笔收集整理的這篇文章主要介紹了 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_IDNUMBER

NAMEVARCHAR2(64)

PARAMETER1VARCHAR2(64)

PARAMETER2VARCHAR2(64)

PARAMETER3VARCHAR2(64)

WAIT_CLASS_IDNUMBER

WAIT_CLASS#NUMBER

WAIT_CLASSVARCHAR2(64)

1.3 查看等待事件總數：

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

COUNT(*)

----------

1116

1.4 查看等待事件分類情況：

/* Formatted on 2010/8/11 16:08:55 (QP5 v5.115.810.9015) */

SELECTwait_class#,

wait_class_id,

wait_class,

COUNT( * )AS"count"

FROMv$event_name

GROUPBYwait_class#, wait_class_id, wait_class

ORDERBYwait_class#;

WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASScount

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

01893977003 Other717

14217450380 Application17

23290255840 Configuration24

34166625743 Administrative54

43875070507 Concurrency32

53386400367 Commit2

62723168908 Idle94

72000153315 Network35

81740759767 User I/O45

94108307767 System I/O30

102396326234 Scheduler7

113871361733 Cluster50

12644977587 Queueing9

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:

SQL> select name, parameter1, parameter2, parameter3 from v$event_name where name='buffer busy waits';

NAMEPARAMETER1 PARAMETER2 PARAMETER3

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

buffer busy waitsfile#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 是你從等待事件中看到的值

anda.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 2010/8/12 11:00:56 (QP5 v5.115.810.9015) */

SELECTCHR(TO_CHAR(BITAND(p1,-16777216))/16777215)

|| CHR(TO_CHAR(BITAND(p1,16711680))/65535)

"Lock",

TO_CHAR(BITAND(p1,65535))"Mode"

FROMv$session_wait

WHEREevent ='enqueue'

Oracle 的enqueue 包含以下模式：

模式代碼	解釋
1	Null mode
2	Sub-Share
3	Sub-Exclusive
4	Share
5	Share/Sub-Exclusive
6	Exclusive

Oracle的enqueue 有如下類型：

Enqueue 縮寫	縮寫解釋
BL	Buffer Cache management
BR	Backup/Restore
CF	Controlfile transaction
CI	Cross-instance 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	High-water 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[A-p]	Library Cache Lock
LS	Log start or switch
MM	Mount Definition
MR	Media recovery
N[A-Z]	Library Cache bin
PE	Alter system set parameter =value
PF	Password file
PI	Parallel slaves
PR	Process startup
PS	Parallel slave synchronization
Q[A-Z]	Row Cache
RO	Object Reuse
RT	Redo Thread
RW	Row Wait
SC	System Commit Number
SM	SMON
SN	Sequence Number
SQ	Sequence Number Enqueue
SR	Synchronized replication
SS	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	User-defined 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

http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/WE1/Default.aspx

13.Free buffer waits

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

當數據庫中出現比較嚴重的free buffer waits等待事件時，可能的原因是：

（1）data buffer 太小，導致空閑空間不夠

（2）內存中的臟數據太多，DBWR無法及時將這些臟數據寫到磁盤中以釋放空間

這個等待事件包含2個參數：

File#：需要讀取的數據塊所在的數據文件的文件號。

Block#：需要讀取的數據塊塊號。

14.Latch free

在10g之前的版本里，latch free 等待事件代表了所有的latch等待，在10g以后，一些常用的latch事件已經被獨立了出來：

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行。

所以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名稱。

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 等待事件。

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

這個等待事件包含兩個參數：