一。 db file parallel write等待事件
引自如下blog：
http://oradbpedia.com/wiki/Wait_Events_-_db_file_parallel_write
db文件並行寫
db文件並行寫等待事件屬於Oracle數據庫寫入程序（DBWR）進程，因為它是將塊從SGA寫入數據文件的唯一進程。當是寫入時，DBWR進程編譯一組臟塊，將批處理交給操作系統，並等待db文件並行寫事件以完成I / O。
雖然用戶會話從來沒有遇到db文件並行寫等待事件，但這並不意味着它們從不會受到影響。如果寫完成等待或空閑緩沖區等待事件顯示在用戶會話中，則它們可能受到db文件並行寫事件的影響。
如果用戶會話需要修改恰好在DBWR寫批處理中的塊，則它必須等待寫完成等待事件，直到該批塊完全寫入磁盤。如果批量大，或I / O子系統速度慢，則DBWR進程將需要等待I / O完成的額外時間，因此將需要正在寫入塊的用戶會話。
如果用戶會話正在經歷空閑緩沖器等待事件，並且等待數量穩定增加，這意味着SGA中空閑塊不足。如果緩沖區緩存太小，或者DBWR無法跟上塊臟的速率，就會發生這種情況。 DBWR進程無法跟上臟塊的原因之一是它花費了太多時間在db文件並行寫事件上。
參數：
P1 = Oracle正在寫入的文件數。
P2 =要寫入的塊數。
P3 =與P2相同的I / O請求總數，因為不使用多塊I / O。
由於P1和P2報告的是文件和塊的數量，而不是絕對文件和塊的數量，因此DBA無法確定正在寫入哪些對象。但是，等待寫入完成等待或空閑緩沖區等待事件的用戶會話指示其P1和P2值中的絕對文件和塊編號。
常見原因和措施
db文件並行寫延遲通常是慢I / O子系統或較差I / O配置的症狀。這包括數據庫文件布局不當，I / O控制器比率不正確，條帶大小和/或RAID級別錯誤，以及磁盤不足（即有幾個高容量磁盤與多個低容量磁盤）。 DBA需要查看平均I / O時間。良好的數據庫和I / O子系統應提供不超過2厘秒的平均I / O等待時間。
如果這是一個問題，DBA應通過映射從裝載點到控制器和控制器到物理磁盤組的I / O路由，並確保數據庫文件的正確放置來檢查I / O配置。此功能的命令是平台。具體和不幸的是，通常需要管理員權限。對於在Sun平台上使用Veritas Volume Manager配置的存儲系統，DBA可能能夠使用vxprint -ht命令。 DBA還應該使用sar -d，iostat -dxn或等效工具從操作系統級別監視使用情況（即I / O吞吐量和瓶頸）。如果一些磁盤長時間（即幾乎100％忙）被命中，並且平均隊列長度大於3，則DBA需要重新安排一些數據庫文件。
除了確保I / O子系統配置正確並且數據庫文件已正確放置之外，DBA還應使DBWR進程（如果平台）提供非阻塞I / O（DISK_ASYNC_IO = TRUE）。支持異步I / O。
較大的寫批處理增加了DBWR I / O等待時間，特別是在數據文件放置不當的環境中。一個確定的標志，寫批處理太大是當用戶會話開始等待寫完成等待事件。在Oracle 8i之前，_DB_BLOCK_WRITE_BATCH參數確定了DBWR寫批量大小，並且值可以在X $ KVII中看到。它被列為DB寫入程序IO叢集。在8i及更高版本中，此參數由_DB_WRITER_CHUNK_WRITES替換，並列為DBWR寫入塊。引入了一個新參數_DB_WRITER_MAX_WRITES以限制未完成的DBWR I / O數量。 DBA應確保批量大小不會大到導致寫入完全等待和更長的db文件並行寫入，並且也不會小到導致長臟隊列和空閑緩沖區等待。另外，請記住，自8i以來，Oracle所做的改進應該使寫批處理問題休息，DBA不應該混亂。寫完成等待事件在8i之前的版本中是普遍的。
之前的Oracle 8i
SQL> select * from x $ kvii其中kviitag ='kcbswc';
Oracle 8i及更高版本
SQL> select * from x $ kvii其中kviitag在（'kcbswc'，'kcbscw'）;
當DB_BLOCK_MAX_DIRTY_TARGET參數設置得太低時，它也可能導致對db文件的過度等待並行寫入和寫入完全等待事件。此參數用於影響執行所需的時間量。實例恢復。當臟緩沖區的數量超過參數的值時，DBWR將把臟緩沖區寫入磁盤。這稱為增量檢查點。較小的值提供較短的實例恢復時間，但是它可能導致DBWR進程變得多活動，特別是在正在修改大量緩沖區的活動數據庫中。這反過來可能導致過多的寫完成等待和更長的db文件並行寫時間。此參數在9i中被隱藏，DBA不應該關心它。
診斷
對於系統級診斷，請查詢V $ SYSTEM_EVENT視圖以確定AVERAGE_WAIT是否是問題。
SQL> select * from v $ system_event where event ='db file parallel write';
當在V$SYSTEM_EVENT時，還要查找伴隨事件。
SQL> select * from v $ system_event
SQL> where event in（'write complete waits'，'free buffer waits'）;
此事件發生在DBWR中。它表示DBWR正在對文件和塊執行並行寫入。當最后一個I / O轉到磁盤時，等待結束.Wait時間：
Wait until all of the I/Os are completed.
Parameter Description
requests This indicates the total number of I/O requests, which will be the same as blocks.
interrupt
timeout This indicates the timeout value in centiseconds to wait for the IO completion.
二. log file parallel write 等待事件
引自如下blog：
http://oracle-dox.net/McGraw.Hill-Oracle.Wait.Interf/8174final/LiB0036.html
日志文件並行寫
日志文件並行寫等待事件有三個參數：文件，塊和請求。在Oracle數據庫10g中，此等待事件屬於系統I / O等待類。在處理日志文件並行寫等待事件時，記住以下關鍵思想。
（1）日志文件並行寫事件僅屬於LGWR進程。
（2）緩慢的LGWR可以影響前台進程提交時間。
（3）重要的日志文件並行寫等待時間很有可能是I / O問題。
常見原因，診斷和操作
由於db文件並行寫等待事件僅屬於DBWR進程，因此日志文件並行寫等待事件僅屬於LGWR進程。當到了寫入時，LGWR進程通過向操作系統發出一系列系統寫入調用將重做緩沖區寫入聯機重做日志。 LGWR進程等待日志文件並行寫事件的寫入完成。 LGWR進程在滿足_LOG_IO_SIZE閾值時，在日志緩沖區中有1MB的重做條目，以及由DBWR進程發布時，在提交時，回滾時，每三秒鍾尋找重做塊一次寫入一次。
雖然用戶會話從來不經歷日志文件並行寫等待事件，但它們可能受到緩慢的LGWR進程的影響。緩慢的LGWR進程可以放大日志文件同步等待，用戶會話在提交或回滾期間等待。在LGWR完成寫入之前，用戶會話將不會獲得提交或回滾完成確認。第7章有關於日志文件同步等待事件的更多細節。
要查看的關鍵數據庫統計信息是日志文件並行寫入和日志文件同步等待事件的系統級TIME_WAITED和AVERAGE_WAIT，因為它們是相互關聯的：
SQL> select event，time_waited，average_wait from v $ system_event where（'log file parallel write'，'log file sync'）;
EVENT TIME_WAITED AVERAGE_WAIT
------------------------- ----------- ------------
log file parallel write 11315158 .508570816
log file sync 7518513 .497255756
如果日志文件並行寫入平均等待時間大於10ms（或1cs），這通常表示緩慢的I / O吞吐量。修復與db文件並行寫入等待相同。如果重做日志位於裸設備上，並且操作系統支持異步I / O，則啟用異步寫入。對於文件系統上的重做日志，請使用同步直接寫入。
不幸的是，你不能產生多個LGWR進程。在這種情況下，關鍵是沒有別的東西共享重做日志文件的安裝點。確保為安裝點提供服務的控制器不會過載。將重做日志移動到更高速的磁盤也將有所幫助。
我們強烈建議您避免將重做日志放在RAID5磁盤上，但我們也了解，很多時候，您沒有選擇或說話。您可以在www.baarf.com發泄您的沮喪。
除了提高I / O吞吐量，還可以減少重做條目的數量。這將提供一些救濟，但不是治愈。只要可能，請使用NOLOGGING選項。應使用NOLOGGING選項創建或重建索引。 CTAS操作也應使用此選項。
注意：
NOLOGGING選項不適用於正常的DML操作，例如插入，更新和刪除。使用NOLOGGING選項創建的對象不可恢復，除非在損壞之前執行備份。如果必須進行額外備份，則通過不記錄而保存的I / O將用於備份。 FORCE LOGGING模式下的數據庫將記錄所有更改（臨時表空間中的更改除外），而不管表空間和對象設置如何。
以較高的回滾段使用率為代價的較低提交頻率也可以提供一些緩解。
高提交頻率導致LGWR進程過度活動，並且當與慢I / O吞吐量耦合時將僅放大日志文件並行寫等待。
應用程序可能在循環中處理大量數據並提交每個更改，這會導致日志緩沖區被過度刷新。在這種情況下，將應用程序修改為以較低的頻率提交。也可能有很多短會話登錄到數據庫，執行。快速DML操作和注銷。
在這種情況下，可能需要審查應用程序設計。您可以使用以下查詢查明誰正在提交頻繁：
SQL> select sid，value from v $ sesstat where statistic＃=（select statistic＃from v $ statname where name ='user commits'）order by value desc;
- Another evidence of excessive commits is high redo wastage.
SQL> select b.name, a.value, round(sysdate - c.startup_time) days_old from v$sysstat a, v$statname b, v$instance c where a.statistic# = b.statistic# and b.name in ('redo wastage','redo size');
NAME VALUE DAYS_OLD
--------------- --------------- ---------------
redo size 249289419360 5
redo wastage 2332945528 5
檢查作業調度程序，查看熱備份是否在高峰時間運行。他們可以創建大量的重做條目，這反過來增加日志文件並行寫等待。熱備份應在非高峰時間運行，並且表空間應盡快從熱備份模式中移除。
最后，小心不要一次堵塞LGWR有太多的重做條目。這可能發生在大日志緩沖區，因為三分之一閾值也較大，並保存更多的重做條目。當滿足三分之一閾值時，如果LGWR進程尚未激活，則執行后台寫入。並且重做條目的數量可能太多，LGWR一次處理，導致擴展的日志文件並行寫入等待。所以想法是流LGWR寫。這可以通過降低由初始化參數_LOG_IO_SIZE控制的三分之一閾值來實現。
默認情況下，_LOG_IO_SIZE是LOG_BUFFER的1/3或1MB（以較小者為准），以日志塊表示。查詢X $ KCCLE.LEBSZ的日志塊大小。通常，它是512字節。
例如，如果LOG_BUFFER為2,097,152字節（2MB），日志塊大小為512字節，則_LOG_IO_SIZE的默認值為1,365個使用的日志塊。在這個大小，LGWR進程變得懶惰，通常只寫在事務終止（同步寫）或從3秒超時喚醒。您應該將_LOG_IO_SIZE設置為相當於64K。這樣，你仍然可以有一個更大的日志緩沖區，以適應檢查點后的緩沖區空間的尖峰，但是當緩沖區中有64K個重做條目時，寫入將開始，假設沒有用戶提交或回滾，LGWR睡眠在此期間沒有超時。
筆記：
這種方法不是沒有開銷。 LGWR寫操作需要重做復制和重做寫鎖存器。因此，更有效的LGWR過程將增加這些鎖存器上的負載。如果這些鎖存器當前具有高SLEEPS，則不要減小_LOG_IO_SIZE。但是，如果條件允許您更改_LOG_IO_SIZE，則必須通過查詢V $ LATCH視圖來監視其隨時間的影響。確保在實施更改之前獲得基線。
您可以使用以下查詢來查找每個寫入的重做日志塊的平均數量和平均LGWR I / O大小（以字節為單位）：
SQL> select v（a.value / b.value）+ 0.5,0）as avg_redo_blks_per_write，round（（a.value / b.value）+ 0.5,0）* c.lebsz as avg_io_size from v $ sysstat a， v $ sysstat b，x $ kccle c where c.lenum = 1 and a.name ='redo blocks written'和b.name ='redo writes';
AVG_REDO_BLKS_PER_WRITE AVG_IO_SIZE
----------------------- -----------
8 8192