本篇文章給大家分享的是有關(guān)oracle常見(jiàn)的等待事件有哪些，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話(huà)不多說(shuō)，跟著小編一起來(lái)看看吧。

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),札達(dá)企業(yè)網(wǎng)站建設(shè),札達(dá)品牌網(wǎng)站建設(shè),網(wǎng)站定制,札達(dá)網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,札達(dá)網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M(mǎn)足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專(zhuān)業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶(hù)成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

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í)。
在新的版本中，第二種情況已經(jīng)被獨(dú)立出來(lái)，以read by other session取代~
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:

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#

2.Buffer  latch

內(nèi)存中數(shù)據(jù)塊的存放位置是記錄在一個(gè)hash列表（cache buffer chains）當(dāng)中的。 當(dāng)一個(gè)會(huì)話(huà)需要訪問(wèn)某個(gè)數(shù)據(jù)塊時(shí)，它首先要搜索這個(gè)hash 列表，從列表中獲得數(shù)據(jù)塊的地址，然后通過(guò)這個(gè)地址去訪問(wèn)需要的數(shù)據(jù)塊，這個(gè)列表Oracle會(huì)使用一個(gè)latch來(lái)保護(hù)它的完整性。 當(dāng)一個(gè)會(huì)話(huà)需要訪問(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ù)塊被頻繁訪問(wèn)，就是我們通常說(shuō)的熱快問(wèn)題。

這個(gè)等待事件有兩個(gè)參數(shù)：
Latch addr： 會(huì)話(huà)申請(qǐng)的latch在SGA中的虛擬地址，通過(guò)以下的SQL語(yǔ)句可以根據(jù)這個(gè)地址找到它對(duì)應(yīng)的Latch名稱(chēng)：
select * from v$latch a,v$latchname b where 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)榉Q(chēng)為控制文件并行寫(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)等待。
 
這個(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( 發(fā)散)，可能會(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)的情況有索引的訪問(wèn)（除IFFS外的方式），回滾操作，以ROWID的方式訪問(wèn)表中的數(shù)據(jù)，重建控制文件，對(duì)文件頭做DUMP等。這里的sequential也并非指的是Oracle 按順序的方式來(lái)訪問(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í)行等操作。 或者意味著PGA中空閑空間不足。
 
這個(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的模式。

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í)，可能的原因是：
--data buffer 太小，導(dǎo)致空閑空間不夠
--內(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)。

--查詢(xún)阻塞的語(yǔ)句：
SELECT /*+ ORDERED USE_HASH(H,R) */
 h.sid hold_sid, holds.username h_user, holds.lockwait h_lockwait, holds.status h_status, holds.module h_module, holds.row_wait_obj# h_obj, holds.row_wait_row# h_row,
 r.sid wait_sid, waits.username w_user, waits.lockwait w_lockwait, waits.status w_status, waits.module w_module, waits.row_wait_obj# w_obj, waits.row_wait_row# w_row,
 h.type h_type, h.id1 h_id1, h.id2 h_id2, h.lmode h_lmode, h.request h_request, h.ctime h_ctime, h.block h_block,
 r.type r_type, r.id1 r_id1, r.id2 r_id2, r.lmode r_lmode, r.request r_request, r.ctime r_ctime, r.block r_block,
 'alter system kill session ''' || holds.sid || ',' || holds.serial# ||
 '''; -- kill -9 ' || nvl(holdp.spid, 'null') killhold,
 holdsql.sql_text hsql,
 waitsql.sql_text wsql
  FROM v$lock    h,
       v$lock    r,
       v$session holds,
       v$session waits,
       v$process holdp,
       v$sqlarea holdsql,
       v$sqlarea waitsql
 WHERE h.BLOCK = 1 AND
       r.BLOCK = 0 AND
       h.TYPE <> 'MR' AND
       r.TYPE <> 'MR' AND
       h.id1 = r.id1 AND
       h.id2 = r.id2 AND
       h.sid = holds.sid AND
       r.sid = waits.sid AND
       holds.paddr = holdp.addr(+) AND
       holds.sql_address = holdsql.address(+) AND
       holds.sql_hash_value = holdsql.hash_value(+) AND
       waits.sql_address = waitsql.address(+) AND
       waits.sql_hash_value = waitsql.hash_value(+);

14.Latch free

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

這個(gè)等待事件有三個(gè)參數(shù)：
--Address: 會(huì)話(huà)等待的latch 地址。
--Number： latch號(hào)，通過(guò)這個(gè)號(hào)，可以從v$latchname 視圖中找到這個(gè)latch 的相關(guān)的信息。

15.Library cache lock

這個(gè)等待時(shí)間發(fā)生在不同用戶(hù)在共享中由于并發(fā)操作同一個(gè)數(shù)據(jù)庫(kù)對(duì)象導(dǎo)致的資源爭(zhēng)用的時(shí)候，比如當(dāng)一個(gè)用戶(hù)正在對(duì)一個(gè)表做DDL 操作時(shí)，其他的用戶(hù)如果要訪問(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)。
 
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等待事件，可以考慮如下方法：
--增加redo buffer的大小。
--提升磁盤(pán)的I/O性能
 
19.Log file sequential read

這個(gè)等待事件通常發(fā)生在對(duì)redo log信息進(jìn)行讀取時(shí)，比如在線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ā)生在在線日志切換（log file switch）時(shí)，需要切換的在線日志還沒(méi)有被歸檔進(jìn)程（ARCH）歸檔完畢的時(shí)候。 當(dāng)在線日志文件切換到下一個(gè)日志時(shí)，需要確保下一個(gè)日志文件已經(jīng)被歸檔進(jìn)程歸檔完畢，否則不允許覆蓋那個(gè)在線日志信息（否則會(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è)在線日志切換到下一個(gè)在線日志時(shí)，必須保證要切換到的在線日志上的記錄的信息（比如一些臟數(shù)據(jù)塊產(chǎn)生的redo log）被寫(xiě)到磁盤(pán)上（checkpoint），這樣做的原因是，如果一個(gè)在線日志文件的信息被覆蓋，而依賴(lài)這些redo 信息做恢復(fù)的數(shù)據(jù)塊尚未被寫(xiě)到磁盤(pán)上（checkpoint），此時(shí)系統(tǒng)down掉的話(huà)，Oracle將沒(méi)有辦法進(jìn)行實(shí)例恢復(fù)。

在v$log 視圖里記錄了在線日志的狀態(tài)。 通常來(lái)說(shuō)，在線日志有三種狀態(tài)。
--Active: 這個(gè)日志上面保護(hù)的信息還沒(méi)有完成checkpoint。
--Inactive： 這個(gè)日志上面保護(hù)的信息已完成checkpoint。
--Current： 當(dāng)前的日志。
 
如果系統(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。

以下幾種情況，可能產(chǎn)生這個(gè)等待：
--高提交頻率
解決方法是簡(jiǎn)單的消除不必要的提交，事務(wù)是工作單元。工作單元應(yīng)該是全部成功或全部失敗。
--緩慢的I/O子系統(tǒng)
較高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待時(shí)間。頻繁的提交會(huì)弄亂數(shù)據(jù)庫(kù)布局和IO子系統(tǒng)。解決辦法是將日志文件放裸設(shè)備上或綁定在RAID 0或RAID 0+1中，而不是綁定在RAID 5中。
--過(guò)大的日志緩沖區(qū)
過(guò)大的日志緩沖區(qū)也可能延長(zhǎng)log file sync等待。大型的日志緩沖區(qū)減少后臺(tái)寫(xiě)入的數(shù)量，允許LGWR變得懶惰，并導(dǎo)致更多的重做條目堆積在日志緩沖區(qū)中。同時(shí)可以調(diào)整參數(shù)_LOG_IO_SIZE參數(shù)，其默認(rèn)值是LOG_BUFFER的1/3或1MB，取兩者之中較小的值。換句話(huà)說(shuō)，你可以具有較大的日志緩沖區(qū)，但較小的_LOG_IO_SIZE將增加后臺(tái)寫(xiě)入，從而減少log file sync的等待時(shí)間.
--過(guò)小的日志緩沖區(qū)
過(guò)小的日志緩沖區(qū)，還會(huì)導(dǎo)致log buffer space等待
--日志組多少與日志大小不合適

這個(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é)議信息。
--Breaks：零表示服務(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訪問(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é)議信息。
--Breaks：零表示服務(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 訪問(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ù)。

以上就是oracle常見(jiàn)的等待事件有哪些，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。