主頁 > 知識庫 > Oracle中常見的33個等待事件小結

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

一．等待事件的相關知識

1.1 等待事件主要可以分為兩類，即空閑(IDLE)等待事件和非空閑(NON-IDLE)等待事件。
1). 空閑等待事件指ORACLE正等待某種工作，在診斷和優(yōu)化數(shù)據(jù)庫的時候，不用過多注意這部分事件。
2). 非空閑等待事件專門針對ORACLE的活動，指數(shù)據(jù)庫任務或應用運行過程中發(fā)生的等待，這些等待事件是在調(diào)整數(shù)據(jù)庫的時候需要關注與研究的。

在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 查看等待事件總數(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

1.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

1.5 相關的幾個視圖
V$SESSION：代表數(shù)據(jù)庫活動的開始，視為源起。
V$SESSION_WAIT：視圖用以實時記錄活動SESSION的等待情況，是當前信息。
V$SESSION_WAIT_HISTORY：是對V$SESSION_WAIT的簡單增強，記錄活動SESSION的最近10次等待。
V$SQLTEXT：當數(shù)據(jù)庫出現(xiàn)瓶頸時，通?？梢詮腣$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的生命周期相關，而并不記錄歷史信
息，所以ORACLE提供視圖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）沒有關系。這個事件發(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
這是一個后臺等待事件，它同樣和用戶的并行操作沒有關系，它是由后臺進程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)了阻塞和等待，可以關聯(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';

Oracle 的enqueue 包含以下模式：

模式代碼
解釋
1
Null (NULL)
2
Row-S(SS)
3
Row-X(SX)
4
Share(S)
5
S/Row-X(SSX)
6
Exclusive(X)

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

Parallel slave synchronization
Q[A-Z]
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
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
當一個會話將數(shù)據(jù)塊從磁盤讀到內(nèi)存中時，它需要到內(nèi)存中找到空閑的內(nèi)存空間來存放這些數(shù)據(jù)塊，當內(nèi)存中沒有空閑的空間時，就會產(chǎn)生這個等待；除此之外，還有一種情況就是會話在做一致性讀時，需要構造數(shù)據(jù)塊在某個時刻的前映像（image），此時需要申請內(nèi)存來存放這些新構造的數(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 的相關的信息。
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ū)懭氲模栽谧x取時也是按照順序的方式來讀取的。

這個等待事件包含三個參數(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文件中可以找到相關的錯誤信息。

這個等待事件沒有參數(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ā)送請求，服務器端處理完客戶端請求后，將結果返回給客戶端，并繼續(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í)行完畢后將結果通過dblink返給發(fā)出SQL的數(shù)據(jù)庫，在等待數(shù)據(jù)從其他數(shù)據(jù)庫中通過dblink傳回的過程中，如果數(shù)據(jù)在遠程數(shù)據(jù)庫上處理時間很久，或者有大量的結果集需要返回，或者網(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)絡問題導致服務器無法及時地將信息或者處理結果發(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ù)。

您可能感興趣的文章:

oracle 常見等待事件及處理方法

標簽：湘潭仙桃銅川湖南崇左衡水黃山蘭州

巨人網(wǎng)絡通訊聲明：本文標題《Oracle中常見的33個等待事件小結》，本文關鍵詞；如發(fā)現(xiàn)本文內(nèi)容存在版權問題，煩請?zhí)峁┫嚓P信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡，涉及言論、版權與本站無關。

佳木斯湛栽影视文化发展公司

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

QQ咨詢

電話咨詢