[[207469]]

相關(guān)知識(shí)

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

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

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

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

SQL> desc v$event_name; 
  名稱(chēng)                  是否為空? 類(lèi)型 
 ----------------------------------------- -------- --------------- 
 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. 查看等待事件分類(lèi)情況

/* 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)的幾個(gè)視圖

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

V$SESSION_WAIT：視圖用以實(shí)時(shí)記錄活動(dòng)SESSION的等待情況，是當(dāng)前信息。

V$SESSION_WAIT_HISTORY：是對(duì)V$SESSION_WAIT的簡(jiǎn)單增強(qiáng)，記錄活動(dòng)SESSION的最近10次等待。

V$SQLTEXT：當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)瓶頸時(shí)，通?？梢詮腣$SESSION_WAIT找到那些正在等待資源的SESSION，

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

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

WRH#_ACTIVE_SESSION_HISTORY: 是V$ACTIVE_SESSION_HISTORY在AWR的存儲(chǔ)地。

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

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

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

33個(gè)常見(jiàn)的等待事件

1. Buffer busy waits 

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

常見(jiàn)的兩種是：

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

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

當(dāng)一個(gè)會(huì)話(huà)修改一個(gè)數(shù)據(jù)塊時(shí)，是按照以下步驟來(lái)完成的：

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

Buffer busy waits等待事件常見(jiàn)于數(shù)據(jù)庫(kù)中存在熱塊的時(shí)候，當(dāng)多個(gè)用戶(hù)頻繁地讀取或者修改同樣的數(shù)據(jù)塊時(shí)，這個(gè)等待事件就會(huì)產(chǎn)生。 如果等待的時(shí)間很長(zhǎng)，我們?cè)贏WR或者statspack 報(bào)告中就可以看到。

這個(gè)等待事件有三個(gè)參數(shù)。查看有幾個(gè)參數(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#  

在下面的示例中，查詢(xún)的方法和這個(gè)一樣，所以其他事件對(duì)參數(shù)的查詢(xún)將不做過(guò)多的說(shuō)明。

File#: 等待訪(fǎng)問(wèn)數(shù)據(jù)塊所在的文件id號(hào)。

Blocks： 等待訪(fǎng)問(wèn)的數(shù)據(jù)塊號(hào)。

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

2. Buffer latch

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

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

• Buffer chains太長(zhǎng)，導(dǎo)致會(huì)話(huà)搜索這個(gè)列表花費(fèi)的時(shí)間太長(zhǎng)，使其他的會(huì)話(huà)處于等待狀態(tài)。
• 同樣的數(shù)據(jù)塊被頻繁訪(fǎng)問(wèn)，就是我們通常說(shuō)的熱快問(wèn)題。

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

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

Latch addr： 會(huì)話(huà)申請(qǐng)的latch在SGA中的虛擬地址。

通過(guò)以下的SQL語(yǔ)句可以根據(jù)這個(gè)地址找到它對(duì)應(yīng)的Latch名稱(chēng)：

/* 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 列表中的索引值，當(dāng)這個(gè)參數(shù)的值等于s 0xfffffff時(shí)，說(shuō)明當(dāng)前的會(huì)話(huà)正在等待一個(gè)LRU latch。

3. Control file parallel write

當(dāng)數(shù)據(jù)庫(kù)中有多個(gè)控制文件的拷貝時(shí)，Oracle 需要保證信息同步地寫(xiě)到各個(gè)控制文件當(dāng)中，這是一個(gè)并行的物理操作過(guò)程，因?yàn)榭刂莆募⑿袑?xiě)，當(dāng)發(fā)生這樣的操作時(shí)，就會(huì)產(chǎn)生control file parallel write等待事件。

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

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

當(dāng)系統(tǒng)出現(xiàn)日志切換過(guò)于頻繁的情形時(shí)，可以考慮適當(dāng)?shù)卦龃笕罩疚募拇笮?lái)降低日志切換頻率。

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

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

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

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

Requests： 寫(xiě)入控制請(qǐng)求的I/O 次數(shù)。

4. Control file sequential read

當(dāng)數(shù)據(jù)庫(kù)需要讀取控制文件上的信息時(shí)，會(huì)出現(xiàn)這個(gè)等待事件，因?yàn)榭刂莆募男畔⑹琼樞驅(qū)懙模宰x取的時(shí)候也是順序的，因此稱(chēng)為控制文件順序讀，它經(jīng)常發(fā)生在以下情況：

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

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

File#： 要讀取信息的控制文件的文件號(hào)。

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

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

5. Db file parallel read

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

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

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

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

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

6. Db file parallel write

這是一個(gè)后臺(tái)等待事件，它同樣和用戶(hù)的并行操作沒(méi)有關(guān)系，它是由后臺(tái)進(jìn)程DBWR產(chǎn)生的，當(dāng)后臺(tái)進(jìn)程DBWR向磁盤(pán)上寫(xiě)入臟數(shù)據(jù)時(shí)，會(huì)發(fā)生這個(gè)等待。

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

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

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

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

Timeouts： 等待的超時(shí)時(shí)間。

7. Db file scattered read

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

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

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

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

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

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

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

8. Db file sequential read

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

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

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

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

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

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

9. Db file single write

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

當(dāng)這個(gè)等待事件很明顯時(shí)，需要考慮是不是數(shù)據(jù)庫(kù)中的數(shù)據(jù)文件數(shù)量太大，導(dǎo)致Oracle 需要花較長(zhǎng)的時(shí)間來(lái)做所有文件頭的更新操作(checkpoint)。

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

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

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

Blocks： 需要更新的數(shù)據(jù)塊數(shù)目(通常來(lái)說(shuō)應(yīng)該等于1)。

10. Direct path read

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

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

Descriptor address: 一個(gè)指針，指向當(dāng)前會(huì)話(huà)正在等待的一個(gè)direct read I/O。

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

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

11. Direct path write

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

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

Descriptor address: 一個(gè)指針，指向當(dāng)前會(huì)話(huà)正在等待的一個(gè)direct I/O.

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

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

12. Enqueue

Enqueue 這個(gè)詞其實(shí)是lock 的另一種描述語(yǔ)。

當(dāng)我們?cè)贏WR 報(bào)告中發(fā)現(xiàn)長(zhǎng)時(shí)間的enqueue 等待事件時(shí)，說(shuō)明數(shù)據(jù)庫(kù)中出現(xiàn)了阻塞和等待，可以關(guān)聯(lián)AWR報(bào)告中的enqueue activity部分來(lái)確定是哪一種鎖定出現(xiàn)了長(zhǎng)時(shí)間等待。

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

Name： enqueue 的名稱(chēng)和類(lèi)型。

Mode： enqueue的模式。

可以使用如下SQL 查看當(dāng)前會(huì)話(huà)等待的enqueue名稱(chēng)和類(lèi)型：

/* 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

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

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

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

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

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

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

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

14. Latch free

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

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以后的版本中并不常見(jiàn)，而是以具體的Latch 等待事件出現(xiàn)。

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

Address: 會(huì)話(huà)等待的latch 地址。

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

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

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

15. Library cache lock

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

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

Handle address: 被加載的對(duì)象的地址。

Lock address： 鎖的地址。

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

Namespace： 被加載對(duì)象在v$db_object_cache 視圖中namespace名稱(chēng)。

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

這個(gè)等待事件和library cache lock 一樣是發(fā)生在共享池中并發(fā)操作引起的事件。通常來(lái)講，如果Oracle 要對(duì)一些PL/SQL 或者視圖這樣的對(duì)象做重新編譯，需要將這些對(duì)象pin到共享池中。如果此時(shí)這個(gè)對(duì)象被其他的用戶(hù)特有，就會(huì)產(chǎn)生一個(gè)library cache pin的等待。

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

Handle address: 被加載的對(duì)象的地址。

Lock address： 鎖的地址。

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

Namespace： 被加載對(duì)象在v$db_object_cache 視圖中namespace名稱(chēng)。

17. Log file parallel write

后臺(tái)進(jìn)程LGWR 負(fù)責(zé)將log buffer當(dāng)中的數(shù)據(jù)寫(xiě)到REDO 文件中，以重用log buffer的數(shù)據(jù)。如果每個(gè)REDO LOG組里面有2個(gè)以上的成員，那么LGWR進(jìn)程會(huì)并行地將REDO 信息寫(xiě)入這些文件中。

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

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

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

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

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

18. Log buffer space

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

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

(1)增加redo buffer的大小。

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

19. Log file sequential read

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

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

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

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

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

20. Log file single write

這個(gè)等待事件發(fā)生在更新redo log文件的文件頭時(shí)，當(dāng)為日志組增加新的日志成員時(shí)或者redo log的sequence號(hào)改變時(shí)，LGWR 都會(huì)更新redo log文件頭信息。

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

Log#： 寫(xiě)入的redo log組的編號(hào)。

Block#：寫(xiě)入的數(shù)據(jù)塊號(hào)。

Blocks：寫(xiě)入的數(shù)據(jù)塊個(gè)數(shù)。

21. Log file switch(archiving needed)

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

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

這個(gè)等待事件沒(méi)有參數(shù)。

22. Log file switch(checkpoint incomplete)

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

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

Active: 這個(gè)日志上面保護(hù)的信息還沒(méi)有完成checkpoint。

Inactive： 這個(gè)日志上面保護(hù)的信息已完成checkpoint。

Current： 當(dāng)前的日志。

Oracle 在做實(shí)例恢復(fù)時(shí)，會(huì)使用狀態(tài)為current和Active的日志進(jìn)行實(shí)例恢復(fù)。

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

這個(gè)等待事件沒(méi)有參數(shù)。

23. Log file sync

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

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

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

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

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

Buffer#: redo buffer 中需要被寫(xiě)入到磁盤(pán)中的buffer。

24. SQL*Net break/reset to client

當(dāng)出現(xiàn)這個(gè)等待事件時(shí)，說(shuō)明服務(wù)器端在給客戶(hù)端發(fā)送一個(gè)斷開(kāi)連接或者重置連接的請(qǐng)求，正在等待客戶(hù)的響應(yīng)，通常的原因是服務(wù)器到客戶(hù)端的網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的。

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

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

25. SQL*Net break/reset to dblink

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

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

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

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

26. SQL*Net message from client

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

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

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

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

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

27. SQL*Net message from dblink

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

這個(gè)等待事件也是一個(gè)空閑等待事件。

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

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

#bytes: 服務(wù)器端通過(guò)dblink 收到的來(lái)自另一個(gè)服務(wù)器端消息的字節(jié)數(shù)。

28. SQL*Net message to client

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

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

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

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

29. SQL*Net message to dblink

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

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

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

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

30. SQL*Net more data from client

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

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

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

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

31. SQL*Net more data from dblink

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

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

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

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

32. SQL*Net more data to client

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

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

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

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

33. SQL*Net more data to dblink

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

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

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

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