【效能調整】等待事件(四) 常見等待事件（二）

等待事件(四)db & ctrl file io相關的等待事件

Control file parallel write

Db file parallel read

Db file parallel write

Db file scattered read

Db file sequential read

Db file single write

Control file parallel write

這個event發生在當session等待寫控制檔案請求完成時。從8.0.5版本開始，CKPT程式每三秒寫日誌的checkpoint到控制檔案，oracle在進行恢復操作時使用這個資訊。並且，當使用nologging或者unrecoverable選項來完成DML做操時，oracle仍然要在控制檔案中記錄不可恢復的SCN。另外RMAN也在控制檔案中記錄備份和恢復的資訊。

一般的寫控制檔案情況：

1， ckpt將重做日誌的檢查點寫入控制檔案

2， arch更新控制檔案中有關歸檔日誌相關資訊

3， lgwr在日誌切換時更新控制檔案

4，使用nologging操作dml時，在控制檔案記錄不可恢復的SCN

5， RMAN在控制檔案中記錄備份與恢復資訊

對於control file parallel write事件來說並沒有blocking session，會話是在等待os和io子系統完成控制檔案寫時被阻塞。會話在執行控制檔案寫時，擁有CF佇列，故其他session必須在這個佇列上等待。如果在系統範圍這個等待事件比較多，可能意味著寫控制檔案太慢，這個慢是相對的，可以結合log 相關的等待時間來判斷，很多情況下是由於日誌切換頻率太快導致。如果是前臺程式在等待control file parallel write事件，且有較高的time waited,有可能是因為使用了nologging操作在更新資料，這時候需要更新控制檔案中的不可恢復的SCN。

SQL> select a.TOTAL_WAITS,a.TIME_WAITED,a.WAIT_CLASS

2 from v$system_event a where a.EVENT = 'control file parallel write' ;

TOTAL_WAITS TIME_WAITED WAIT_CLASS

----------- ----------- ----------------------------------------------------------------

2658291 697557 System I/O

SQL> select a.PARAMETER1 p1, a.PARAMETER2 p2, a.PARAMETER3 p3

2 from v$event_name a

3 where a.name = 'control file parallel write';

P1 P2 P3

--------------- --------------- ---------------

files blocks requests

引數說明：

P1: 檔案號

P2: block號

P3: IO請求號

Db file parallel read

這個事件和任何並行操作沒有關係（如並行DML和並行查詢），而是當資料庫進行恢復操作時，一部分需要恢復並且需要更改的資料塊從資料檔案中並行讀取時產生的事件。

QL> select name,parameter1 p1,parameter2 p2,parameter3 p3

2 from v$event_name a where a.NAME = 'db file parallel read';

NAME P1 P2 P3

-------------------- --------------- --------------- ---------------

db file parallel read files blocks requests

引數說明：

P1: file號

P2: block號

P3: IO請求的總數

等待時間：no timeouts，會話將等待所有io結束。

Db file parallel write

同樣的，也和並行dml操作相關。這個event屬於DBWR程式（這個程式負責將髒塊寫入資料檔案）。阻塞DBWR的是作業系統的io子系統。當然DBWR寫磁碟也會影響到該磁碟上其他session的讀。

DBWR將一組髒資料編排為’write batch’，然後釋出多個IO請求寫這個’write batch’到資料檔案，然後在db file parallel write 事件上等待，知道IO全部完成，但是當使用非同步IO時，DBWR不能帶整個批量寫入完成，僅僅等待一定百分比的IO操作完成後，就將空閒緩衝區推到LRU鏈以使其可用。

DBWR查詢髒塊的時機：

每隔三秒一次

前臺提交需要清除緩衝區內容

當滿足_DB_LARGE_DIRTY_QUEUE / _DB_BLOCK_MAX_DIRTY_TARGET / FAST_START_MTTR_TARGET閾值。

緩慢的DBWR操作可以造成session在write complete waits(不允許修改正在傳輸到磁碟的塊)或者free buffer waits(DBWR不能滿足釋放緩衝區的需求)事件等待。

相關查詢：

SQL> SELECT s.event, s.time_waited, s.average_wait

2 FROM v$system_event s

3 WHERE s.event IN ('db file parallel write', 'free buffer waits',

4 'write complete waits');

EVENT TIME_WAITED AVERAGE_WAIT

---------------------------------------------------------------- ----------- ------------

db file parallel write 4937689 0

SQL> SELECT *

2 FROM v$sysstat

3 WHERE NAME IN ('write clones created in background',

4 'write clones created in foreground')

5 ;

STATISTIC# NAME CLASS VALUE

---------- ---------------------------------------------------------------- ---------- ----------

93 write clones created in foreground 8 24649

94 write clones created in background 8 26

SQL> select name,parameter1 p1,parameter2 p2,parameter3 p3

2 from v$event_name a where a.NAME = 'db file parallel write';

NAME P1 P2 P3

-------------------- --------------- --------------- ---------------

db file parallel wri requests interrupt timeout

te

SQL>

引數說明：

P1: requests，dbwr寫入’write batch’的大小

P2: interrupt中斷

P3: timeout超時

Db file scattered read

當會話釋出一個讀入多個資料塊的IO請求時提交該事件。ORACLE會話等待多個連續的資料塊(由初始引數DB_FILE_MULTIBLOCK_READ_COUNT指定)從磁碟讀入到SGA中。

該事件是在全表掃描或索引快速全域性掃描時發生的典型事件。

初始化引數db_file_multiblock_read_count(MBRC)決定了讀取資料塊的最大數目，有兩種情況會造成多塊讀取操作被分成幾次操作：

MBRC因子不能跨越整個區，如果一個區包含10個塊，MBRC因子=8，那麼多塊讀取會發布兩次讀取呼叫，一次8個資料塊，一次2個資料塊。

要讀取的多塊有，有一部分已在CACHE中，這時多塊讀取操作被分化成幾次來完成。

在存在較多的連線或遷移的行時，oracle使用單塊io呼叫尋求每個連線的或遷移的行，在dba_tables檢視中可以看chain_cnt欄位。

select hash_value,

child_number,

lpad(' ', 2 * depth) || operation || ' ' || options ||

decode(id, 0, substr(optimizer, 1, 6) || ' Cost=' || to_char(cost)) operation,

object_name object,

cost,

cardinality,

round(bytes / 1024) kbytes

from v$sql_plan

where hash_value in

(select a.sql_hash_value

from v$session a, v$session_wait b

where a.sid = b.sid

and b.event = 'db file scattered read')

order by hash_value, child_number, id;

上面的查詢顯示了當前正在執行的產生db file scattered read的sql語句。

SQL> select a.PARAMETER1 p1, a.PARAMETER2 p2, a.PARAMETER3 p3

2 from v$event_name a

3 where a.name = 'db file scattered read';

P1 P2 P3

--------------- --------------- ---------------

file# block# blocks

引數：

P1: 檔案號

P2: 起始的塊號

P3: 塊數

同樣的，也可以根據塊號和塊數，從dba_extents裡面查詢對應的資料物件。

Db file sequential read

單塊讀取產生的等待事件。大量的等待則通常說明正在執行大量的索引讀取，需要考慮是否是sql有問題。

在確定使用索引是否合理的時候，需要稽核考慮索引叢集因子的大小，如果值接近於表中塊的數量，則表中大多數行就被排序，如果值接近於行的數量，則行接近隨即排序。另外，有寫引數會對CBO計算使用索引的代繳產生影響：optimizer_index_cost_adj，optimizer_index_caching

和db file scattered read差不多，可以看看查詢：

SQL> select a.PARAMETER1 p1, a.PARAMETER2 p2, a.PARAMETER3 p3

2 from v$event_name a

3 where a.name = 'db file sequential read';

P1 P2 P3

--------------- --------------- ---------------

file# block# blocks

SQL>

引數一樣，只不過是blocks為1不變，因為是單塊讀取。

也可以查詢到當前正在等待中的資料物件。

Db file single write

這個事件是由DBWR發出的，發生的時機是當oracle正在更新資料檔案頭，典型的是在做checkpoint的時候。當資料庫有過量的資料檔案的時候可能會發生。

SQL> select a.PARAMETER1 p1, a.PARAMETER2 p2, a.PARAMETER3 p3

2 from v$event_name a

3 where a.name = 'db file single write';

P1 P2 P3

--------------- --------------- ---------------

file# block# blocks

p1: 檔案號

p2: 起始block

p3: 寫入的block數量，此時為1

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16179598/viewspace-675635/，如需轉載，請註明出處，否則將追究法律責任。

【效能調整】等待事件(四) 常見等待事件（二）

相關文章