常見等待事件

1、1. Buffer busy waitsà多個進程視圖以不兼容的模式獲取buffer block上的buffer pin時從本質(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ù)塊上的

2、數(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)生。 如果等待的時間

3、很長，我們在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

4、# class#File#: 等待訪問數(shù)據(jù)塊所在的文件id號。Blocks： 等待訪問的數(shù)據(jù)塊號。ID： 在10g之前，這個值表示一個等待時間的原因，10g之后則表示等待事件的類別。模擬：#會話1：SQL> select sid from v$mystat where rownum=1; SID- 48SQL> begin 2 for i in 1 . 100000 loop 3 update buffer_busy set name='gmk' where id=1; 4 commit; 5 end loop; 6 end; 7 /PL/SQL procedure

5、 successfully completed.#會話2：SQL> select sid from v$mystat where rownum=1; SID- 40SQL> begin 2 for i in 1 . 100000 loop 3 update buffer_busy set name='gmk' where id=2; 4 commit; 5 end loop; 6 end; 7 /PL/SQL procedure successfully completed.#會話3：直接查詢v$session_wait可能查不出結(jié)果，因為循環(huán)的時間太短，SQL&g

6、t; select event,sid,p1,p2,p3 from v$session_wait_history where sid in(40,48);EVENT SID P1 P2 P3- - - - -SQL*Net message to client 40 1650815232 1 0log file sync 40 1911 2060565 0buffer busy waits 40 4 2868 1latch: cache buffers chains 40 2362724272 177 0latch: cache buffers chains 40 2363144776 177

7、0buffer busy waits 40 4 2868 1latch: redo allocation 40 2347671688 209 0buffer busy waits 40 4 2868 1buffer busy waits 40 4 2868 1buffer busy waits 40 4 2868 1SQL*Net message to client 48 1650815232 1 0EVENT SID P1 P2 P3- - - - -log file sync 48 1138 2084833 0buffer busy waits 48 3 11412 20buffer bu

8、sy waits 48 4 2868 1buffer busy waits 48 3 11412 20buffer busy waits 48 4 2868 1buffer busy waits 48 3 176 23buffer busy waits 48 3 10620 24buffer busy waits 48 4 2868 1buffer busy waits 48 3 240 3120 rows selected.SQL> select * from v$waitstat where count>0;CLASS COUNT TIME- - -data block 973

9、5 2201segment header 1 1file header block 30 91undo header 4863 556undo block 225 89SQL> select sql_text from v$sqlarea where sql_text like '%buffer_busy%'SQL_TEXT-begin for i in 1 . 100000 loop update buffer_busy set name='gmk' where id=1; commit; end loop; end;select sql_text fr

10、om V$sqlarea where (address,hash_value) in (select sql_address,sql_hash_value from v$session where event like '%buffer busy%')SELECT name, parameter1, parameter2, parameter3 FROM v$event_name WHERE name = 'buffer busy waits'begin for i in 1 . 100000 loop update buffer_busy set name=&

11、#39;gmk' where id=2; commit; end loop; end;select sql_text from v$sqlarea where sql_text like '%buffer_busy%'select * from buffer_busy6 rows selected.SQL> select sql_text from v$sqlarea where sql_text like '%BUFFER_BUSY%'SQL_TEXT-UPDATE BUFFER_BUSY SET NAME='gmk' WHERE

12、 ID=1SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),NVL(SUM(C2),:"SYS_B_1") FROM (SELECT /*+ IGNORE_WHERE_CLAUSE

13、 NO_PARALLEL("BUFFER_BUSY") FULL("BUFFER_BUSY") NO_PARALLEL_INDEX("BUFFER_BUSY") */ :"SYS_B_2" AS C1, CASE WHEN "BUFFER_BUSY"."ID"=:"SYS_B_3" THEN :"SYS_B_4" ELSE :"SYS_B_5" END AS C2 FROM "TEST_WAIT"

14、."BUFFER_BUSY" "BUFFER_BUSY") SAMPLESUBselect sql_text from v$sqlarea where sql_text like '%BUFFER_BUSY%'UPDATE BUFFER_BUSY SET NAME='gmk' WHERE ID=22. Buffer latch -只在邏輯讀時產(chǎn)生內(nèi)存中數(shù)據(jù)塊的存放位置是記錄在一個hash列表（cache buffer chains）當中的。當一個會話需要訪問某個數(shù)據(jù)塊時，它首先要搜索這個hash 列表，從列表中獲得數(shù)據(jù)塊的

15、地址，然后通過這個地址去訪問需要的數(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，或者使用參DB_BLOCK_LRU_LA

16、TCHES來增加latch的數(shù)量，以便于更多的會話可以獲得latch，這兩種方法可以同時使用。1這個等待事件有兩個參數(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 whereaddr=latch addr - 這里的latch addr 是你從等待事件中看到的值and a.latch#=b.latch#;chain

17、#： 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)等

18、待。當系統(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取的

19、時候也是順序的，因此稱為控制文件順序讀，它經(jīng)常發(fā)生在以下情況：備份控制文件RAC 環(huán)境下不同實例之間控制文件的信息共享讀取控制文件的文件頭信息讀取控制文件其他信息這個等待事件有三個參數(shù)：File#： 要讀取信息的控制文件的文件號。Block#： 讀取控制文件信息的起始數(shù)據(jù)塊號。Blocks： 需要讀取的控制文件數(shù)據(jù)塊數(shù)目。注：該等待事件并不代表數(shù)據(jù)庫有問題，一個健康的系統(tǒng)，物理讀應是除空閑等待事件外的最大等待事件，在一個正常的rac集群中，該事件排在top10也是正常的，因為實例間共享一份控制文件，對控制問價你的讀取時很頻繁的，如果被其他等待事件擠出千十，反倒會比較奇怪。5. Db file

20、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ù)。#db file parallel read也可以發(fā)生在緩沖預取的時候，即預先將數(shù)據(jù)塊讀取到buffer cache中。6. Db file parallel write這是一個后臺等待事

21、件，它同樣和用戶的并行操作沒有關(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不再需要一直等

22、到所有數(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( 分散)，可能會導

23、致很多人認為它是以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/

24、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ā)生在一種

25、情況下，就是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ù)，因為這

26、樣做沒有意義。這些數(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í)行等操作。或者意味著PGA中空閑空間不足。這個等待事件有三個參數(shù)：Descriptor address: 一個指針，指向當前會話正在 等待的一個direct read I/O。First dba: descriptor address 中最舊的一個I/O數(shù)據(jù)

27、塊地址。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ù)塊地址。B

28、lock cnt: descriptor address 上下文中涉及的有效地 buffer 數(shù)量。 12. EnqueueEnqueue 這個詞其實是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的模式?？梢允褂萌缦耂QL 查看當前會話等待的enqueue名稱和類型：/* Formatted on 6/27/2011 1:31:48 PM

29、 (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)存空間來存

30、放這些數(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 f

31、ree在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 activitylatch freelatch: Change Notification Hash table latchlatch: In memory undo latchlatch: MQL Tracking Latchlatch: PX hash ar

32、ray latchlatch: Undo Hint Latchlatch: WCR: processes HTlatch: WCR: synclatch: cache buffer handleslatch: cache buffers chainslatch: cache buffers lru chainlatch: call allocationlatch: change notification client cache latchlatch: checkpoint queue latchlatch: enqueue hash chainslatch: gc elementlatch:

33、 gcs resource hashlatch: ges resource hash listlatch: lob segment dispenser latchlatch: lob segment hash table latchlatch: lob segment query latchlatch: messageslatch: object queue header operationlatch: parallel query alloc bufferlatch: redo allocationlatch: redo copylatch: redo writinglatch: row c

34、ache objectslatch: session allocationlatch: shared poollatch: undo global datalatch: virtual circuit queues已選擇33行。10gr2 rac:sysORCL> select name from v$event_name where name like 'latch%' order by 1;NAME-latch activitylatch freelatch: Change Notification Hash table latchlatch: In memory u

35、ndo latchlatch: KCL gc element parent latchlatch: MQL Tracking Latchlatch: Undo Hint Latchlatch: cache buffer handleslatch: cache buffers chainslatch: cache buffers lru chainlatch: checkpoint queue latchlatch: enqueue hash chainslatch: gcs resource hashlatch: ges resource hash listlatch: library cac

36、helatch: library cache locklatch: library cache pinlatch: messageslatch: object queue header heaplatch: object queue header operationlatch: parallel query alloc bufferlatch: redo allocationlatch: redo copylatch: redo writinglatch: row cache objectslatch: session allocationlatch: shared poollatch: un

37、do global datalatch: virtual circuit queues29 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 lo

38、ck這個等待事件發(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:sysORCL> select name from v$event_n

39、ame where name like 'library%' order by 1;NAME-library cache load locklibrary cache locklibrary cache pinlibrary cache revalidationlibrary cache shutdown 16. Library cache pin這個等待事件和library cache lock 一樣是發(fā)生在共享池中并發(fā)操作引起的事件。通常來講，如果Oracle 要對一些PL/SQL 或者視圖這樣的對象做重新編譯，需要將這些對象pin到共享池中。如果此時這個對象被其他的用戶特

40、有，就會產(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)這個

41、等待事件的瓶頸，主要的原因可能是磁盤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必

42、須確保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號。Blo

43、ck#： 讀取的數(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）時，需要切換的在線日志還沒

44、有被歸檔進程（ARCH）歸檔完畢的時候。 當在線日志文件切換到下一個日志時，需要確保下一個日志文件已經(jīng)被歸檔進程歸檔完畢，否則不允許覆蓋那個在線日志信息（否則會導致歸檔日志信息不完整）。出現(xiàn)這樣的等待事件通常是由于某種原因?qū)е翧RCH 進程死掉，比如ARCH進程嘗試向目的地寫入一個歸檔文件，但是沒有成功（介質(zhì)失效或者其他原因），這時ARCH進程就會死掉。 如果發(fā)生這種情況，在數(shù)據(jù)庫的alert log文件中可以找到相關(guān)的錯誤信息。這個等待事件沒有參數(shù)。 22. Log file switch(checkpoint incomplete)當一個在線日志切換到下一個在線日志時，必須保證要切換到的在

45、線日志上的記錄的信息（比如一些臟數(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和Activ

46、e的日志進行實例恢復。如果系統(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ù)的操作，

47、這個等待事件就叫作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)絡(luò)

48、不穩(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 等待事件。很顯然，這是一個空閑等待，如果客戶端不再向服務器