之前整理過一篇文章：

Oracle 等待事件

http://blog.csdn.net/tianlesoftware/archive/2010/05/31/5635934.aspx

一． 等待事件的相關知識：

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 檢視等待事件總數：

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

COUNT(*)

----------

1116

1.4 檢視等待事件分類情況：

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

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:

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

/* Formatted on 2010/8/12 11:00:56 (QP5 v5.115.810.9015) */

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'

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

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事件已經被獨立了出來：

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

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

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