[[207469]]

相關(guān)知識

1. 等待事件主要可以分為兩類，即空閑(IDLE)等待事件和非空閑(NON-IDLE)等待事件。

1). 空閑等待事件指ORACLE正等待某種工作，在診斷和優(yōu)化數(shù)據(jù)庫的時候，不用過多注意這部分事件。

2). 非空閑等待事件專門針對ORACLE的活動，指數(shù)據(jù)庫任務或應用運行過程中發(fā)生的等待，這些等待事件 是在調(diào)整數(shù)據(jù)庫的時候需要關(guān)注與研究的。 在Oracle 10g中的等待事件有872個，11g中等待事件1116個?？梢酝ㄟ^v$event_name 視圖來查看等待事件的相關(guān)信息。

2. 查看v$event_name視圖的字段結(jié)構(gòu)

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)  

3 .查看等待事件總數(shù)

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  

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  

5 .相關(guān)的幾個視圖

V$SESSION：代表數(shù)據(jù)庫活動的開始，視為源起。

V$SESSION_WAIT：視圖用以實時記錄活動SESSION的等待情況，是當前信息。

V$SESSION_WAIT_HISTORY：是對V$SESSION_WAIT的簡單增強，記錄活動SESSION的最近10次等待。

V$SQLTEXT：當數(shù)據(jù)庫出現(xiàn)瓶頸時，通常可以從V$SESSION_WAIT找到那些正在等待資源的SESSION，

通過SESSION的SID，聯(lián)合V$SESSION和V$SQLTEXT視圖就可以捕獲這些SESSION正在執(zhí)行的SQL語句。

V$ACTIVE_SESSION_HISTORY:是ASH的核心，用以記錄活動SESSION的歷史等待信息，每秒采樣一次，這部分內(nèi)容記錄在內(nèi)存中，期望值是記錄一個小時的內(nèi)容。

WRH#_ACTIVE_SESSION_HISTORY: 是V$ACTIVE_SESSION_HISTORY在AWR的存儲地。

V$ACTIVE_SESSION_HISTORY中 的信息會被定期(每小時一次)的刷新到負載庫中，并缺省保留一個星期用于分析。

DBA_HIST_ACTIVE_SESS_HISTORY:視圖是WRH#_ACTIVE_SESSION_HISTORY視圖和其他幾個視圖的聯(lián)合展現(xiàn)，通常通過這個視圖進行歷史數(shù)據(jù)的訪問。

V$SYSTEM_EVENT: 由于V$SESSION記錄的是動態(tài)信息，和SESSION的生命周期相關(guān)，而并不記錄歷史信息，所以O(shè)RACLE提供視圖V$SYSTEM_EVENT來記錄數(shù)據(jù)庫自啟動以來所有等待事件的匯總信息。通過這個視圖，用戶可以迅速獲得數(shù)據(jù)庫運行的總體概況。

33個常見的等待事件

1. Buffer busy waits 

從本質(zhì)上講，這個等待事件的產(chǎn)生僅說明了一個會話在等待一個Buffer(數(shù)據(jù)塊)，但是導致這個現(xiàn)象的原因卻有很多種。

常見的兩種是：

• 當一個會話試圖修改一個數(shù)據(jù)塊，但這個數(shù)據(jù)塊正在被另一個會話修改時。
• 當一個會話需要讀取一個數(shù)據(jù)塊，但這個數(shù)據(jù)塊正在被另一個會話讀取到內(nèi)存中時。

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

當一個會話修改一個數(shù)據(jù)塊時，是按照以下步驟來完成的：

• 以排他的方式獲得這個數(shù)據(jù)塊(Latch)
• 修改這個數(shù)據(jù)塊。
• 釋放Latch。

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

這個等待事件有三個參數(shù)。查看有幾個參數(shù)我們可以用以下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#  

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

File#: 等待訪問數(shù)據(jù)塊所在的文件id號。

Blocks： 等待訪問的數(shù)據(jù)塊號。

ID： 在10g之前，這個值表示一個等待時間的原因，10g之后則表示等待事件的類別。

2. Buffer latch

內(nèi)存中數(shù)據(jù)塊的存放位置是記錄在一個hash列表(cache buffer chains)當中的。當一個會話需要訪問某個數(shù)據(jù)塊時，它首先要搜索這個hash 列表，從列表中獲得數(shù)據(jù)塊的地址，然后通過這個地址去訪問需要的數(shù)據(jù)塊，這個列表Oracle會使用一個latch來保護它的完整性。 當一個會話需要訪問這個列表時，需要獲取一個Latch，只有這樣，才能保證這個列表在這個會話的瀏覽當中不會發(fā)生變化。

產(chǎn)生buffer latch的等待事件的主要原因是：

• Buffer chains太長，導致會話搜索這個列表花費的時間太長，使其他的會話處于等待狀態(tài)。
• 同樣的數(shù)據(jù)塊被頻繁訪問，就是我們通常說的熱快問題。

產(chǎn)生buffer chains太長，我們可以使用多個buffer pool的方式來創(chuàng)建更多的buffer chains，或者使用參數(shù)DB_BLOCK_LRU_LATCHES來增加latch的數(shù)量，以便于更多的會話可以獲得latch，這兩種方法可以同時使用。

這個等待事件有兩個參數(shù)：

Latch addr： 會話申請的latch在SGA中的虛擬地址。

通過以下的SQL語句可以根據(jù)這個地址找到它對應的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 列表中的索引值，當這個參數(shù)的值等于s 0xfffffff時，說明當前的會話正在等待一個LRU latch。

3. Control file parallel write

當數(shù)據(jù)庫中有多個控制文件的拷貝時，Oracle 需要保證信息同步地寫到各個控制文件當中，這是一個并行的物理操作過程，因為控制文件并行寫，當發(fā)生這樣的操作時，就會產(chǎn)生control file parallel write等待事件。

控制文件頻繁寫入的原因很多，比如：

• 日志切換太過頻繁，導致控制文件信息相應地需要頻繁更新。
• 系統(tǒng)I/O 出現(xiàn)瓶頸，導致所有I/O出現(xiàn)等待。

當系統(tǒng)出現(xiàn)日志切換過于頻繁的情形時，可以考慮適當?shù)卦龃笕罩疚募拇笮斫档腿罩厩袚Q頻率。

當系統(tǒng)出現(xiàn)大量的control file parallel write 等待事件時，可以通過比如降低控制文件的拷貝數(shù)量，將控制文件的拷貝存放在不同的物理磁盤上的方式來緩解I/O 爭用。

這個等待事件包含三個參數(shù)：

Files： Oracle 要寫入的控制文件個數(shù)。

Blocks： 寫入控制文件的數(shù)據(jù)塊數(shù)目。

Requests： 寫入控制請求的I/O 次數(shù)。

4. Control file sequential read

當數(shù)據(jù)庫需要讀取控制文件上的信息時，會出現(xiàn)這個等待事件，因為控制文件的信息是順序?qū)懙模宰x取的時候也是順序的，因此稱為控制文件順序讀，它經(jīng)常發(fā)生在以下情況：

• 備份控制文件
• RAC 環(huán)境下不同實例之間控制文件的信息共享
• 讀取控制文件的文件頭信息
• 讀取控制文件其他信息

這個等待事件有三個參數(shù)：

File#： 要讀取信息的控制文件的文件號。

Block#： 讀取控制文件信息的起始數(shù)據(jù)塊號。

Blocks： 需要讀取的控制文件數(shù)據(jù)塊數(shù)目。

5. Db file parallel read

這是一個很容易引起誤導的等待事件，實際上這個等待事件和并行操作(比如并行查詢，并行DML)沒有關(guān)系。 這個事件發(fā)生在數(shù)據(jù)庫恢復的時候，當有一些數(shù)據(jù)塊需要恢復的時候，Oracle會以并行的方式把他們從數(shù)據(jù)文件中讀入到內(nèi)存中進行恢復操作。

這個等待事件包含三個參數(shù)：

Files： 操作需要讀取的文件個數(shù)。

Blocks： 操作需要讀取的數(shù)據(jù)塊個數(shù)。

Requests： 操作需要執(zhí)行的I/O次數(shù)。

6. Db file parallel write

這是一個后臺等待事件，它同樣和用戶的并行操作沒有關(guān)系，它是由后臺進程DBWR產(chǎn)生的，當后臺進程DBWR向磁盤上寫入臟數(shù)據(jù)時，會發(fā)生這個等待。

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

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

這個等待事件有兩個參數(shù)：

Requests： 操作需要執(zhí)行的I/O次數(shù)。

Timeouts： 等待的超時時間。

7. Db file scattered read

這個等待事件在實際生產(chǎn)庫中經(jīng)?？梢钥吹剑@是一個用戶操作引起的等待事件，當用戶發(fā)出每次I/O需要讀取多個數(shù)據(jù)塊這樣的SQL 操作時，會產(chǎn)生這個等待事件，最常見的兩種情況是全表掃描(FTS： Full Table Scan)和索引快速掃描(IFFS： index fast full scan)。

這個名稱中的scattered( 分散)，可能會導致很多人認為它是以scattered 的方式來讀取數(shù)據(jù)塊的，其實恰恰相反，當發(fā)生這種等待事件時，SQL的操作都是順序地讀取數(shù)據(jù)塊的，比如FTS或者IFFS方式(如果忽略需要讀取的數(shù)據(jù)塊已經(jīng)存在內(nèi)存中的情況)。

這里的scattered指的是讀取的數(shù)據(jù)塊在內(nèi)存中的存放方式，他們被讀取到內(nèi)存中后，是以分散的方式存在在內(nèi)存中，而不是連續(xù)的。

這個等待事件有三個參數(shù)：

File#： 要讀取的數(shù)據(jù)塊所在數(shù)據(jù)文件的文件號。

Block#： 要讀取的起始數(shù)據(jù)塊號。

Blocks： 需要讀取的數(shù)據(jù)塊數(shù)目。

8. Db file sequential read

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

這里的sequential也并非指的是Oracle 按順序的方式來訪問數(shù)據(jù)，和db file scattered read一樣，它指的是讀取的數(shù)據(jù)塊在內(nèi)存中是以連續(xù)的方式存放的。

這個等待事件有三個參數(shù)：

File#： 要讀取的數(shù)據(jù)塊鎖在數(shù)據(jù)文件的文件號。

Block#： 要讀取的起始數(shù)據(jù)塊號。

Blocks： 要讀取的數(shù)據(jù)塊數(shù)目(這里應該等于1)。

9. Db file single write

這個等待事件通常只發(fā)生在一種情況下，就是Oracle 更新數(shù)據(jù)文件頭信息時(比如發(fā)生Checkpoint)。

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

這個等待事件有三個參數(shù)：

File#: 需要更新的數(shù)據(jù)塊所在的數(shù)據(jù)文件的文件號。

Block#： 需要更新的數(shù)據(jù)塊號。

Blocks： 需要更新的數(shù)據(jù)塊數(shù)目(通常來說應該等于1)。

10. Direct path read

這個等待事件發(fā)生在會話將數(shù)據(jù)塊直接讀取到PGA當中而不是SGA中的情況，這些被讀取的數(shù)據(jù)通常是這個會話私有的數(shù)據(jù)，所以不需要放到SGA作為共享數(shù)據(jù)，因為這樣做沒有意義。這些數(shù)據(jù)通常是來自于臨時段上的數(shù)據(jù)，比如一個會話中SQL的排序數(shù)據(jù)，并行執(zhí)行過程中間產(chǎn)生的數(shù)據(jù)，以及Hash Join，merge join產(chǎn)生的排序數(shù)據(jù)，因為這些數(shù)據(jù)只對當前的會話的SQL操作有意義，所以不需要放到SGA當中。 當發(fā)生direct path read等待事件時，意味著磁盤上有大量的臨時數(shù)據(jù)產(chǎn)生，比如排序，并行執(zhí)行等操作?；蛘咭馕吨鳳GA中空閑空間不足。

這個等待事件有三個參數(shù)：

Descriptor address: 一個指針，指向當前會話正在等待的一個direct read I/O。

First dba: descriptor address 中最舊的一個I/O數(shù)據(jù)塊地址。

Block cnt: descriptor address上下文中涉及的有效的buffer 數(shù)量。

11. Direct path write

這個等待事件和direct path read 正好相反，是會話將一些數(shù)據(jù)從PGA中直接寫入到磁盤文件上，而不經(jīng)過SGA。 這種情況通常發(fā)生在：·使用臨時表空間排序(內(nèi)存不足)·數(shù)據(jù)的直接加載(使用append方式加載數(shù)據(jù))·并行DML操作。

這個等待事件有三個參數(shù)：

Descriptor address: 一個指針，指向當前會話正在等待的一個direct I/O.

First dba: descriptor address 中最舊的一個I/O數(shù)據(jù)塊地址。

Block cnt: descriptor address 上下文中涉及的有效地 buffer 數(shù)量。

12. Enqueue

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

當我們在AWR 報告中發(fā)現(xiàn)長時間的enqueue 等待事件時，說明數(shù)據(jù)庫中出現(xiàn)了阻塞和等待，可以關(guān)聯(lián)AWR報告中的enqueue activity部分來確定是哪一種鎖定出現(xiàn)了長時間等待。

這個等待事件有2個參數(shù)：

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

當一個會話將數(shù)據(jù)塊從磁盤讀到內(nèi)存中時，它需要到內(nèi)存中找到空閑的內(nèi)存空間來存放這些數(shù)據(jù)塊，當內(nèi)存中沒有空閑的空間時，就會產(chǎn)生這個等待;除此之外，還有一種情況就是會話在做一致性讀時，需要構(gòu)造數(shù)據(jù)塊在某個時刻的前映像(image)，此時需要申請內(nèi)存來存放這些新構(gòu)造的數(shù)據(jù)塊，如果內(nèi)存中無法找到這樣的內(nèi)存塊，也會發(fā)生這個等待事件。

當數(shù)據(jù)庫中出現(xiàn)比較嚴重的free buffer waits等待事件時，可能的原因是：

(1)data buffer 太小，導致空閑空間不夠

(2)內(nèi)存中的臟數(shù)據(jù)太多，DBWR無法及時將這些臟數(shù)據(jù)寫到磁盤中以釋放空間

這個等待事件包含2個參數(shù)：

File#： 需要讀取的數(shù)據(jù)塊所在的數(shù)據(jù)文件的文件號。

Block#： 需要讀取的數(shù)據(jù)塊塊號。

14. Latch free

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

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 等待事件出現(xiàn)。

這個等待事件有三個參數(shù)：

Address: 會話等待的latch 地址。

Number： latch號，通過這個號，可以從v$latchname 視圖中找到這個latch 的相關(guān)的信息。

SQL> select * from v$latchname where latch#=number;

Tries: 會話嘗試獲取Latch 的次數(shù)。

15. Library cache lock

這個等待事件發(fā)生在不同用戶在共享中由于并發(fā)操作同一個數(shù)據(jù)庫對象導致的資源爭用的時候，比如當一個用戶正在對一個表做DDL 操作時，其他的用戶如果要訪問這張表，就會發(fā)生library cache lock等待事件，它要一直等到DDL操作完成后，才能繼續(xù)操作。

這個事件包含四個參數(shù)：

Handle address: 被加載的對象的地址。

Lock address： 鎖的地址。

Mode： 被加載對象的數(shù)據(jù)片段。

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 一樣是發(fā)生在共享池中并發(fā)操作引起的事件。通常來講，如果Oracle 要對一些PL/SQL 或者視圖這樣的對象做重新編譯，需要將這些對象pin到共享池中。如果此時這個對象被其他的用戶特有，就會產(chǎn)生一個library cache pin的等待。

這個等待事件也包含四個參數(shù)：

Handle address: 被加載的對象的地址。

Lock address： 鎖的地址。

Mode： 被加載對象的數(shù)據(jù)片段。

Namespace： 被加載對象在v$db_object_cache 視圖中namespace名稱。

17. Log file parallel write

后臺進程LGWR 負責將log buffer當中的數(shù)據(jù)寫到REDO 文件中，以重用log buffer的數(shù)據(jù)。如果每個REDO LOG組里面有2個以上的成員，那么LGWR進程會并行地將REDO 信息寫入這些文件中。

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

這個等待事件有三個參數(shù)：

Files： 操作需要寫入的文件個數(shù)。

Blocks： 操作需要寫入的數(shù)據(jù)塊個數(shù)。

Requests：操作需要執(zhí)行的I/O次數(shù)。

18. Log buffer space

當log buffer 中沒有可用空間來存放新產(chǎn)生的redo log數(shù)據(jù)時，就會發(fā)生log buffer space等待事件。如果數(shù)據(jù)庫中新產(chǎn)生的redo log的數(shù)量大于LGWR 寫入到磁盤中的redo log 數(shù)量，必須等待LGWR 完成寫入磁盤的操作，LGWR必須確保redo log寫到磁盤成功之后，才能在redo buffer當中重用這部分信息。

如果數(shù)據(jù)庫中出現(xiàn)大量的log buffer space等待事件，可以考慮如下方法：

(1)增加redo buffer的大小。

(2)提升磁盤的I/O性能

19. Log file sequential read

這個等待事件通常發(fā)生在對redo log信息進行讀取時，比如在線redo 的歸檔操作，ARCH進程需要讀取redo log的信息，由于redo log的信息是順序?qū)懭氲?，所以在讀取時也是按照順序的方式來讀取的。

這個等待事件包含三個參數(shù)：

Log#： 發(fā)生等待時讀取的redo log的sequence號。

Block#： 讀取的數(shù)據(jù)塊號。

Blocks： 讀取的數(shù)據(jù)塊個數(shù)。

20. Log file single write

這個等待事件發(fā)生在更新redo log文件的文件頭時，當為日志組增加新的日志成員時或者redo log的sequence號改變時，LGWR 都會更新redo log文件頭信息。

這個等待事件包含三個參數(shù)：

Log#： 寫入的redo log組的編號。

Block#：寫入的數(shù)據(jù)塊號。

Blocks：寫入的數(shù)據(jù)塊個數(shù)。

21. Log file switch(archiving needed)

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

出現(xiàn)這樣的等待事件通常是由于某種原因?qū)е翧RCH 進程死掉，比如ARCH進程嘗試向目的地寫入一個歸檔文件，但是沒有成功(介質(zhì)失效或者其他原因)，這時ARCH進程就會死掉。 如果發(fā)生這種情況，在數(shù)據(jù)庫的alert log文件中可以找到相關(guān)的錯誤信息。

這個等待事件沒有參數(shù)。

22. Log file switch(checkpoint incomplete)

當一個在線日志切換到下一個在線日志時，必須保證要切換到的在線日志上的記錄的信息(比如一些臟數(shù)據(jù)塊產(chǎn)生的redo log)被寫到磁盤上(checkpoint)，這樣做的原因是，如果一個在線日志文件的信息被覆蓋，而依賴這些redo 信息做恢復的數(shù)據(jù)塊尚未被寫到磁盤上(checkpoint)，此時系統(tǒng)down掉的話，Oracle將沒有辦法進行實例恢復。

在v$log 視圖里記錄了在線日志的狀態(tài)。通常來說，在線日志有三種狀態(tài)。

Active: 這個日志上面保護的信息還沒有完成checkpoint。

Inactive： 這個日志上面保護的信息已完成checkpoint。

Current： 當前的日志。

Oracle 在做實例恢復時，會使用狀態(tài)為current和Active的日志進行實例恢復。

如果系統(tǒng)中出現(xiàn)大量的log file switch(checkpoint incomplete)等待事件，原因可能是日志文件太小或者日志組太少，所以解決的方法是，增加日志文件的大小或者增加日志組的數(shù)量。

這個等待事件沒有參數(shù)。

23. Log file sync

這是一個用戶會話行為導致的等待事件，當一個會話發(fā)出一個commit命令時，LGWR進程會將這個事務產(chǎn)生的redo log從log buffer里面寫到磁盤上，以確保用戶提交的信息被安全地記錄到數(shù)據(jù)庫中。

會話發(fā)出的commit指令后，需要等待LGWR將這個事務產(chǎn)生的redo 成功寫入到磁盤之后，才可以繼續(xù)進行后續(xù)的操作，這個等待事件就叫作log file sync。

當系統(tǒng)中出現(xiàn)大量的log file sync等待事件時，應該檢查數(shù)據(jù)庫中是否有用戶在做頻繁的提交操作。

這種等待事件通常發(fā)生在OLTP系統(tǒng)上。OLTP 系統(tǒng)中存在很多小的事務，如果這些事務頻繁被提交，可能引起大量的log file sync的等待事件。

這個等待事件包含一個參數(shù)：

Buffer#: redo buffer 中需要被寫入到磁盤中的buffer。

24. SQL*Net break/reset to client

當出現(xiàn)這個等待事件時，說明服務器端在給客戶端發(fā)送一個斷開連接或者重置連接的請求，正在等待客戶的響應，通常的原因是服務器到客戶端的網(wǎng)絡不穩(wěn)定導致的。

這個等待事件包含兩個參數(shù)：Driver id: 服務器和客戶端連接使用的協(xié)議信息。

Break?：零表示服務端向客戶端發(fā)送一個重置(reset)信息，非零表示服務器端向客戶端發(fā)送一個斷開(break)消息。

25. SQL*Net break/reset to dblink

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

這個等待事件有兩個參數(shù)：

Driver id: 服務器和客戶端連接使用的協(xié)議信息。

Break?：零表示服務端向客戶端發(fā)送一個重置(reset)信息，非零表示服務器端向客戶端發(fā)送一個斷開(break)消息。

26. SQL*Net message from client

這個等待事件基本上是最常見的一個等待事件。當一個會話建立成功后，客戶端會向服務器端發(fā)送請求，服務器端處理完客戶端請求后，將結(jié)果返回給客戶端，并繼續(xù)等待客戶端的請求，這時候會產(chǎn)生SQL*Net message from client 等待事件。

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

這個等待事件包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端接收到的來自客戶端消息的字節(jié)數(shù)。

27. SQL*Net message from dblink

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

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

這個事件包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端通過dblink 收到的來自另一個服務器端消息的字節(jié)數(shù)。

28. SQL*Net message to client

這個等待事件發(fā)生在服務器端向客戶端發(fā)送消息的時候。當服務器端向客戶端發(fā)送消息產(chǎn)生等待時，可能的原因是用戶端太繁忙，無法及時接收服務器端送來的消息，也可能是網(wǎng)絡問題導致消息無法從服務器端發(fā)送到客戶端。

這個等待事件有兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端向客戶端發(fā)送消息的字節(jié)數(shù)。

29. SQL*Net message to dblink

這個等待事件和SQL*Net message to client 相同，不過是發(fā)生在數(shù)據(jù)庫服務器和服務器之間的等待事件，產(chǎn)生這個等待的原因可能是遠程服務器繁忙，而無法及時接收發(fā)送過來的消息，也可能是服務器之間網(wǎng)絡問題導致消息無法發(fā)送過來。

這個等待時間包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端通過dblink發(fā)送給另一個服務器消息的字節(jié)數(shù)。

30. SQL*Net more data from client

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

這個等待時間包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端從客戶端接收到消息的字節(jié)數(shù)。

31. SQL*Net more data from dblink

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

這個等待時間包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端通過dblink發(fā)送給另一個服務器消息的字節(jié)數(shù)。

32. SQL*Net more data to client

當服務器端有太多的數(shù)據(jù)需要發(fā)給客戶端時，可能會產(chǎn)生SQL*Net more data to client等待事件，也可能由于網(wǎng)絡問題導致服務器無法及時地將信息或者處理結(jié)果發(fā)送給客戶端，同樣會產(chǎn)生這個等待。

這個等待時間包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端向客戶端發(fā)送消息的字節(jié)數(shù)。

33. SQL*Net more data to dblink

這個等待事件和SQL*Net more data to client 等待時間基本相同，只不過等待發(fā)生在分布式事務中，即本地數(shù)據(jù)庫需要將更多的數(shù)據(jù)通過dblink發(fā)送給遠程數(shù)據(jù)庫。由于發(fā)送的數(shù)據(jù)太多或者網(wǎng)絡性能問題，就會出現(xiàn)SQL*Net more data to dblink等待事件。

這個等待時間包含兩個參數(shù)：

Driver id: 服務器端和客戶端連接使用的協(xié)議信息。

#bytes: 服務器端通過dblink發(fā)送給另一個服務器消息的字節(jié)數(shù)。