【等待事件】等待事件系列（3+4）--System IO（控制文件）+日志類等待
各位技術愛好者，看完本文後，你可以掌握如下的技能，也可以學到一些其它你所不知道的知識，~O(∩_∩)O~：
① 控制文件類等待
② 日志類等待
【推薦】 等待事件系列（1）--User I/O類型（下）
http://blog.itpub.net/26736162/viewspace-2124435/
【推薦】 等待事件系列（1）--User I/O類型（上）
http://blog.itpub.net/26736162/viewspace-2124417/
2016-09-07
【等待事件】System I/O類 等待事件（3.4）--control file single write
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771471&idx=1&sn=5922a52ac6294acf2802f44e2bb0d724&chksm=fe8bba77c9fc336151a61bdf876cb058df0d61d1404d8450cb7771330b6d44309d86dae4bb54&scene=21#wechat_redirect
2016-09-06
【等待事件】System I/O類 等待事件（3.3）--control file sequential read
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771468&idx=1&sn=fc7d83d1a9b12911f3c93d3b5b444e9a&chksm=fe8bba74c9fc3362b58717fca9e95c68d45e701fa2f733a643ba01db7969cca668858272fbfc&scene=21#wechat_redirect
2016-09-04
【等待事件】System I/O類 等待事件（3.2）--control file parallel write
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771458&idx=1&sn=e949dfa5bff65ce4a596005955c5be5a&scene=21#wechat_redirect
2016-09-03
【等待事件】System I/O類 等待事件（3.1）--db file parallel write
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771454&idx=1&sn=e90248954475dfd2c78bdec592405735&scene=21#wechat_redirect
2016-09-01
【等待事件】User I/O類 等待事件（2.10）--所有User I/O類 等待事件總結
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771447&idx=1&sn=22ae192f0d8a161f65514339ad763985&scene=21#wechat_redirect
2016-08-31
【等待事件】User I/O類 等待事件（2.9）--local write wait
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771443&idx=1&sn=02b4ad5ca03052013b69ae6bcb7e3487&scene=21#wechat_redirect
2016-08-30
【等待事件】User I/O類 等待事件（2.8）--read by other session
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771439&idx=1&sn=b3c01eed444cd6e597a63a3ed0687768&scene=21#wechat_redirect
2016-08-29
【等待事件】User I/O類 等待事件（2.7）--direct path read/write temp
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771429&idx=1&sn=50b5684e699165a34087db88e07edb34&scene=21#wechat_redirect
2016-08-27
【等待事件】User I/O類 等待事件（2.6）--direct path write（直接路徑寫、DRW）
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771420&idx=1&sn=458eb18dc26da94debcea62643d15181&scene=21#wechat_redirect
2016-08-26
【等待事件】User I/O類 等待事件（2.5）--direct path read（直接路徑讀、DPR）
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771416&idx=1&sn=b26c3135584c5b60ce14cc0749ac58a7&scene=21#wechat_redirect
2016-08-20
【等待事件】User I/O類 等待事件（2.4）--db file single write
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771403&idx=1&sn=054dd852dac5ac8837fa251f0e84332e&scene=21#wechat_redirect
2016-08-16
【等待事件】User I/O類 等待事件（2.3）--db file parallel read
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771387&idx=1&sn=0037fb89470d8e6dd5ff72714b18a3b7&scene=21#wechat_redirect
2016-08-15
【等待事件】User I/O類 等待事件（2.2）--db file scattered read（數據文件離散讀）
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771379&idx=1&sn=5887eee02885000c1d293adfd04ee044&scene=21#wechat_redirect
2016-08-14
【等待事件】User I/O類 等待事件（2.1）--db file sequential read（數據文件順序讀）
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771376&idx=1&sn=42de046e73190f4e265f81bbb6e3ae00&scene=21#wechat_redirect
2016-08-13
【等待事件】等待事件概述（1）--等待事件的源起和分類
http://mp.weixin.qq.com/s?__biz=MzIzOTA2NjEzNQ==&mid=2454771373&idx=1&sn=1e55af795aae5f641b2c3cc610814ead&scene=21#wechat_redirect
3 System I/O類型
SELECT *
FROM v$event_name d
WHERE d.WAIT_CLASS ='System I/O';
SELECT *
FROM v$event_name
WHERE NAME IN ('db file parallel write');
這個等待事件有3個參數：
Requests： 操作需要執行的I/O次數(DBWR寫入批量的大小-塊數)。
interrupt：(中斷)
timeout：等待的超時時間。
在V$SESSION_WAIT這個視圖裡面，這個等待事件有三個參數P1、P2、P3，其中P1代表Oracle正在寫入的數據文件的數量，P2代表操作將會寫入多少的BLOCK數量，P3在Oracle9i release2版本之前代表總共有多少BLOCK的I/O請求，等於P2的值；在Oracle9i release2版本之後則代表等待I/O完成的超時的時間，單位是百分之一秒。
經過高速緩沖區的所有數據是通過DBWR寫入到磁盤上的。DBWR請求寫入髒塊的I/O後，在此工作結束期間等待db file parallel write事件。
這是一個後台等待事件，它同樣和用戶的並行操作沒有關系，它是由後台進程DBWR產生的，當後台進程DBWR向磁盤上寫入髒數據時，會發生這個等待。
DBWR會批量地將髒數據並行地寫入到磁盤上相應的數據文件中，在這個批次作業完成之前，DBWR將出現這個等待事件。 如果僅僅是這一個等待事件，對用戶的操作並沒有太大的影響，當伴隨著出現free buffer waits等待事件時，說明此時內存中可用的空間不足，這時候會影響到用戶的操作，比如影響到用戶將髒數據塊讀入到內存中。
當出現db file parallel write等待事件時，可以通過啟用操作系統的異步I/O的方式來緩解這個等待。 當使用異步I/O時，DBWR不在需要一直等到所有數據塊全部寫入到磁盤上，它只需要等到這個數據寫入到一個百分比之後，就可以繼續進行後續的操作。
這個等待事件是指Oracle後台進程DBWR等待一個並行寫入文件或者是BLOCK的完成，等待會一直持續到這個並行寫入操作完成。這個等待事件即使在總的等待時間中占的比例比較大也不會對用戶的會話有很大的影響，只有當用戶的會話顯示存在大量的等待時間消耗在"write complete waits" 或者是"free buffer waits"上的時候才會影響到用戶的會話，較明顯的影響是這個寫操作的等待會影響到讀取同一個磁盤上數據的用戶會話的I/O。
① 與其名稱相反，該事件不與任何並行DML操作相關。
② 該等待事件屬於DBWR進程，DBWR進程負責向數據文件寫入髒數據塊的唯一進程，即DBWR進程執行對使用SGA的所有數據庫寫入。阻塞該進程的是操作系統的IO子系統。當然DBWR進程的寫入操作也會對同一磁盤操作的其他會話造成影響。
③ DBWR查找髒塊的時機：
>> 每隔三秒一次的查找。
>> 當前台提交需要清除緩沖區內容時。
>> 當滿足_DB_LARGE_DIRTY_QUEUE/_DB_BLOCK_MAX_DIRTY_TARGET /FAST_START_MTTR_TARGET阈值。
④ 緩慢的DBWR操作可以造成前台會話在write complete waits(前台不允許修改正在傳輸到磁盤的塊)或free buffer waits(DBWR不能滿足釋放緩沖區的需求)事件上。通過以下語句可以獲知該事件的平均等待時間，如果平均等待時間大小10cs，則表明IO緩慢。如果不存在db file parallel write事件，很可能初始化參數disk_async_io=FALSE，這種情況一般發生在AIX和HPUX平台上。
SELECT s.event, s.time_waited, s.average_wait
FROM v$system_event s
WHERE s.event IN ('db file parallel write', 'free buffer waits',
'write complete waits')
相關查詢：
SELECT *
FROM v$sysstat
WHERE NAME IN ('write clones created in background',
'write clones created in foreground')
⑤ 操作說明：DBWR將一組髒數據編成"寫入批量組"，然後發布多個IO請求以將"寫入批量組"寫入數據文件，然後以此事件等待直到IO請求都完成。但是，當使用異步IO時，DBWR不等待整個批量寫入完成，僅等待一定百分比的IO操作完成後，就將空閒緩沖區推到LRU鏈以使其可用。
⑥ 解決方法：
>> 如果平均等待時間長，要選擇使用正確的IO操作。如果數據文件在裸設備上，並且平台支持異步IO，請應該使用異步IO。如果數據文件位於文件系統上，則應該使用同步寫入和直接IO。相關的初始化參數是DISK_ASYNCH_IO和FILESYSTEMIO_OPTIONS。
>> 如果重做位於祼設備上，而數據文件位於文件系統上，則可以設置DISK_ASYNCH_IO=TRUE，FILESYSTEMIO_OPTIONS=DIRECTIO。使用這種方法可以獲得對於祼設備使用異步IO，而對於文件系統使用直接IO的效果。
>> 使用DB_WRITER_PROCESSES選項產生多個DBWR進程。
1、I/O系統的性能緩慢時
db file parallel write等待的發生原因和解決方法如下：
如果DBWR進程上db file parallel write等待時間表現得過長，就可以判斷為I/O系統上有問題。如果DBWR上的db file parallel write等待時間延長，服務器進程就會接連經歷free buffer waits事件或write complete waits事件的等待。這個問題可以通過改善I/O系統解決，改善I/O性能的方法如下：
（1）組合使用裸設備和異步I/O是目前為止的最好方法。
（2）OS級上使用Direct I/O。若CPU數量充足，可以調整db_writer_processes參數值，將DBWR數量增加。多個DBWR具有模擬異步的效果。oracle推薦的DBWR進程是CPU_COUNT/8。
2、I/O工作過多時
頻繁發生檢查點時，DBWR的活動量過多，可能導致DBWR的性能降低。DBWR的性能與整個系統的性能有直接的聯系。將fast_start_mttr_target(MTTR指平均恢復時間,數據庫進行崩潰恢復需要的秒數。)參數值設定過小時，將頻繁發生增量檢查點工作。日志文件過小時，將頻繁發生日志文件的轉換，因此檢查點工作將增加。因Parallel Query發生direct path read時，在truncate、drop、hot backup時也發生檢查點。如果I/O系統上不存在性能問題，但還是廣泛出現db file parallel write等待，就應該檢查是否存在給DBWR帶來不必要的負荷的因素。
3、不能有效使用高速緩存區時
間接改善DBWR性能的另一種方法是合理使用多重緩沖池。與其說這個方法能改善I/O系統的性能，不如說是因為不必要的寫入工作減少，進而減少了DBWR的負擔。
SELECT A.* FROM V$EVENT_NAME A WHERE NAME LIKE 'control file%';
這一類等待事件通常發生在更新控制文件時，例如日志切換、檢查點等發生時，需要更新控制文件內的System Change Number(SCN)所引起的相關等待事件，以下將為這些控制文件所引起的等待事件做詳盡的介紹。
SELECT A.*
FROM V$EVENT_NAME A
WHERE NAME IN ('control file parallel write');
這個等待事件包含三個參數：
files：Oracle要寫入的控制文件個數。
block#：寫入控制文件的數據塊數目。
requests：寫入控制文件請求的I/O次數。
在V$SESSION_WAIT這個視圖裡面，這個等待事件有三個參數P1、P2、P3，這三個參數都設置為同樣的值，代表控制文件對I/O的請求數量。當Oracle更新控制文件的時候是同時更新所有控制文件並寫入同樣的信息。
這個等待事件表明服務器進程(Server Process)在更新所有的控制文件的時候等待I/O的完成。因為控制文件所在的磁盤的I/O過高引起無法完成對所有控制文件的物理寫入，寫入控制文件的這個會話會擁有CF隊列，因此其他的會話都會在這個隊列中等待。
一般環境下，因為更新控制文件的次數不多，因此不怎麼發生control file parallel write等待現象。但如下情況下可能發生與控制文件相關的爭用。
1) 日志文件切換經常發生時：
日志文件過小時，將經常發生日志文件的切換。每當發生日志文件切換時，需要對控制文件進行更新，所以LGWR進程等待control file parallel write事件的時間將延長。
2) 檢查點經常發生時：
MTTR設定得過短或頻繁發生人為的檢查點時，CKPT進程等待control file parallel write事件的時間將延長。
3) nologging引起頻繁的數據文件修改時：
對數據文件在nologging選項下執行修改工作時，為了修改unrecoverable SCN需要更新控制文件。這時，服務器進程將等待control file parallel write事件。
4) I/O系統的性能緩慢時：
最好是將控制文件位於獨立的磁盤空間上，使用裸設備或direct I/O。
control file parallel write等待，通常與control file sequential read等待或enq: CF - contention等待一同出現的情況較多。enq: CF - contention等待是在多個會話為了同時更新控制文件獲得CF鎖的過程中發生的。control file parallel write、control file sequential read、CF - contention等待，全是因為過多的控制文件更新或I/O系統的性能問題引發的。
當server 進程更新所有控制文件時，這個事件可能出現。如果等待很短，可以不用考慮。如果等待時間較長，檢查存放控制文件的物理磁盤I/O 是否存在瓶頸。
多個控制文件是完全相同的拷貝，用於鏡像以提高安全性。對於業務系統，多個控制文件應該存放在不同的磁盤上，一般來說三個是足夠的，如果只有兩個物理硬盤，那麼兩個控制文件也是可以接受的。在同一個磁盤上保存多個控制文件是不具備實際意義的。
當數據庫中有多個控制文件的拷貝時，Oracle 需要保證信息同步地寫到各個控制文件當中，這是一個並行的物理操作過程，因為稱為控制文件並行寫，當發生這樣的操作時，就會產生control file parallel write等待事件。
控制文件頻繁寫入的原因很多，比如：
l 日志切換太過頻繁，導致控制文件信息相應地需要頻繁更新。當系統出現日志切換過於頻繁的情形時，可以考慮適當地增大日志文件的大小來降低日志切換頻率。
l 系統I/O 出現瓶頸，導致所有I/O出現等待。
如果在等待時間中這個等待事件占的比重比較大，可以從如下幾個方面來調整：
l 在確保控制文件不會同時都丟失的前提下，將控制文件的數量減小到最少，降低控制文件的拷貝數量(在確保安全的前提下)。
l 如果系統支持異步I/O，則推薦盡量使用異步I/O，這樣可以實現真正並行的寫入控制文件。
l 將控制文件移動到負載比較低，速度比較快的磁盤上去。
l 將控制文件的拷貝存放在不同的物理磁盤上的方式來緩解I/O 爭用。
SELECT A.*
FROM V$EVENT_NAME A
WHERE NAME IN ('control file sequential read');
這個等待事件有三個參數：
File#：要讀取信息的控制文件的文件號。
Block#：讀取控制文件信息的起始數據塊號。
Blocks：需要讀取的控制文件數據塊數目。
在V$SESSION_WAIT這個視圖裡面，這個等待事件有三個參數P1、P2、P3，其中P1代表正在讀取的控制文件號，通過下面的SQL語句可以知道究竟是具體是哪個控制文件被讀取：
SELECT * FROM X$KCCCF WHERE INDX = <file#>；
P2代表開始讀取的控制文件BLOCK號，它的BLOCK大小和操作系統的BLOCK大小一樣，通常來說是512K，也有些UNIX的是1M或者2M，P3代表會話要讀取BLOCK的數量。一般來說使用參數P1、P2來查詢BLOCK,當然也可以包括參數P3，但是那樣最終就變成了一個多BLOCK讀取，因此我們一般都忽略參數P3。
Wait Time: The wait time is the elapsed time of the read
Parameter
Description
file#
The control file from which the session is reading
block#
Block number in the control file from where the session starts to read. The block size is the physical block size of the port (usually 512 bytes, some UNIX ports have 1 or 2 Kilobytes).
blocks
The number of blocks that the session is trying to read
控制文件連續讀/控制文件單個寫對單個控制文件I/O 存在問題時，這兩個事件會出現。如果等待比較明顯，檢查單個控制文件，看存放位置是否存在I/O 瓶頸。
當數據庫需要讀取控制文件上的信息時，會出現這個等待事件，因為控制文件的信息是順序寫的，所以讀取的時候也是順序的，因此稱為控制文件順序讀，它經常發生在以下情況：
l 備份控制文件
l RAC環境下不同實例之間控制文件的信息共享
l 讀取控制文件的文件頭信息
l 讀取控制文件其他信息
Reading from the control file. This happens in many cases. For example, while:
1、Making a backup of the control files
2、Sharing information (between instances) from the control file
3、Reading other blocks from the control files
4、Reading the header block
讀取控制文件的時候遇到I/O等待就會出現這個等待事件，例如備份控制文件的時候、讀取BLOCK頭部都會引起這個等待事件，等待的時間就是消耗在讀取控制文件上的時間。
如果這個等待事件等待的時間比較長，則需要檢查控制文件所在的磁盤是否很繁忙，如果是，將控制文件移動到負載比較低，速度比較快的磁盤上去。如果系統支持異步I/O，則啟用異步I/O。對於並行服務器來說，如果這種等待比較多，會造成整個數據庫性能下降，因為並行服務器之間的一些同步是通過控制文件來實現的。
解決方式與control file parallel write的解決方式一樣。
首先，該等待事件並不表明數據庫有問題。一個健康的系統，物理讀事件應是除空閒等待事件外的最大等待事件。而該事件在RAC中尤其明顯，依照經驗來看，在一個正常的RAC集群中，該事件應該排在top10中，因為實例間共享同一份控制文件，對控制文件讀取是很頻繁的，如果被其他等待事件擠出前10了，那就得看看是哪些等待事件了。其次，可以查看AWR報告該事件的等待次數，平均等待時間，最大等待時間等信息進行進一步確認。看看這些信息比起日常AWR報告信息是否有明顯的異常。
SELECT A.*
FROM V$EVENT_NAME A
WHERE NAME IN ('control file single write');
P2代表開始讀取的控制文件BLOCK號，它的BLOCK大小和操作系統的BLOCK大小一樣，通常來說是512K，也有些UNIX的是1K或者2K，P3代表會話要讀取BLOCK的數量。一般來說使用參數P1、P2來查詢BLOCK,當然也可以包括參數P3，但是那樣最終就變成了一個多BLOCK讀取，因此我們一般都忽略參數P3。
在V$SESSION_WAIT這個視圖裡面，這個等待事件有三個參數P1、P2、P3，其中P1代表正在讀取的控制文件號，通過下面的SQL語句可以知道究竟是具體是哪個控制文被讀取：
SELECT * FROM X$KCCCF WHERE INDX = <file#>；
這個等待事件出現在寫控制文件的共享信息到磁盤的時候，這是個自動操作，並且通過一個實例來保護的，如果是並行的數據庫服務器，那麼對於並行服務器來說也只能有一個實例能夠執行這個操作。這個事件的等待事件就是寫操作所消耗的時間。
盡管這個事件的是single write，事實上也會出現多BLOCK寫的情況，即P3>1。使用參數P1、P2來查詢檢測BLOCK而不用去考慮P3的值。
如果這個等待事件等待的時間比較長，則需要檢查控制文件所在的磁盤是否很繁忙，如果是，將控制文件移動到負載比較低，速度比較快的磁盤上去。如果系統支持異步I/O，則啟用異步I/O。對於並行服務器來說，如果這種等待比較多，會造成整個數據庫性能下降，因為並行服務器之間的一些同步是通過控制文件來實現的。
解決方式與control file parallel write的解決方式一樣。
REDO對於數據庫來說非常重要，有一系列等待事件和日志相關，通過V$EVENT_NAME視圖可以找到這些等待事件。
我們以11g為主：
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE '%log%';
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE 'log file switch %';
當數據庫日志文件發生切換時出現，LGWR需要關閉當前日志組，切換並打開下一個日志組，在這個切換過程中，數據庫的所有DML操作都處於停頓狀態，直至這個切換完成。
這個等待事件是指執行日志文件切換命令的時候等待日志文件切換完成，Oracle數據庫會每隔五秒鐘就檢測一次是否超時。如果出現這個等待事件，表明花費了很長的時間去切換重做日志文件，此時我們需要去檢查數據庫的告警日志文件查看Oracle後台進程LGWR是否正常在工作。
log file switch引起的等待都是非常重要的，如果出現就應該引起重視，並由DBA介入進行及時處理。
log file switch包含5個子事件：
1. log file switch (archiving needed)，即日志切換（需要歸檔）
這個等待事件出現時通常是因為日志組循環寫滿以後，在需要覆蓋先前日志時，發現日志歸檔尚未完成，出現該等待。由於Redo不能寫出，該等待出現時，數據庫將陷於停頓狀態。
這個等待事件是指當前的重做日志文件准備切換到下一重做日志文件，但是當前重做日志文件因為沒有被歸檔而導致等待，這個等待事件只出現於采用了歸檔方式的Oracle數據庫中。
如果出現這個等待事件，首先應該查看Oracle數據庫的告警日志文件，看是否因為寫歸檔日志文件錯誤導致歸檔進程停止，其次，可以增加歸檔進程的數量或者將歸檔日志文件存放到I/O速度比較快的磁盤上，還可以通過增大和增加重做日志文件的大小和數量來給予歸檔更多的時間。
出現該等待，可能表示I/O存在問題、歸檔進程寫出緩慢、日志切換太快，也有可能是日志組設置不合理、日志文件太小、redo生成太多等原因導致。針對不同原因，可以考慮采用的解決方法有：
① 可以考慮增大日志文件和增加日志組；
② 移動歸檔文件到快速磁盤；
③ 調整log_archive_max_processes參數等；
2. log file switch (checkpoint incomplete)，即日志切換（檢查點未完成）
當一個在線日志切換到下一個在線日志時，必須保證要切換到的在線日志上的記錄的信息（比如一些髒數據塊產生的redo log）被寫到磁盤上（checkpoint），這樣做的原因是，如果一個在線日志文件的信息被覆蓋，而依賴這些redo信息做恢復的數據塊尚未被寫到磁盤上（checkpoint），此時系統down掉的話，Oracle將沒有辦法進行實例恢復。當所有的日志組都寫滿之後。LGWR試圖覆蓋某個日志文件，如果這時數據庫沒有完成寫出由這個日志文件所保護的髒數據時（檢查點未完成），該等待事件出現。該等待出現時，數據庫同樣將陷於停頓狀態。
在日志切換時,會完成一個檢查點操作,如果此檢查點完成的過於緩慢,就會造成此事件的等待,檢查點為什麼會緩慢呢?可能是buffer cache太大因此容納的髒塊太多,DBWR進程太少,調整檢查點頻率的參數設置頻率太低等原因造成的.
在v$log 視圖裡記錄了在線日志的狀態。 通常來說，在線日志有三種狀態。
Active: 這個日志上面保護的信息還沒有完成checkpoint。
Inactive： 這個日志上面保護的信息已完成checkpoint。
Current： 當前的日志。
Oracle 在做實例恢復時，會使用狀態為current和Active的日志進行實例恢復。
如果系統中出現大量的log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志組太少，DBWR寫出速度太慢或者I/O存在問題,所以解決的方法是，考慮增加額外的DBWR或者增加日志文件的大小或者增加日志組的數量。
同時警告日志文件中會記錄如下信息：
Fri Nov 18 14:26:57 2005
Thread 1 cannot allocate new log, sequence 7239
Checkpoint not complete
Current log# 5 seq# 7238 mem# 0: /opt/oracle/oradata/hsmkt/redo05.log
增加日志：
alter database add logfile thread 1 group 3 ('/oradata/backera3/redo03.log') size 256M;
alter database add logfile thread 2 group 4 ('/oradata/backera3/redo04.log') size 256M;
3. log file switch completion
這個等待事件是指由於當前重做日志文件已經被寫滿了而Oracle後台進程LGWR需要完成寫完當前重做日志文件並且要打開一個新的重做日志文件而導致的重做日志文件切換的等待，或者是其他請求需要切換重做日志文件導致等待。
如果當前的重做日志寫滿了，這個時候Oracle數據庫就需要切換重做日志文件來提供足夠的磁盤空間給重做日志寫日志緩存。但是由於一些其他的進程也同樣可以引起重做日志的切換，Oracle數據庫不會同時去切換重做日志兩次，因此，就出現了這個等待事件，在Oracle數據庫早期的版本中還有log_file_switch_checkpoint_incomplete、log_file_switch_archiving_needed、log_file_switch_clearing_log_file的等待事件。
當一個日志文件滿了,oracle要打開另一個日志文件,寫完上一日志文件,准備好下一日志文件,這之間的等待就是此等待事件了,簡單點說,就是為了完成日志文件切換而發生的等待.
4. log file switch (clearing log file)
這發生在DBA發布alter system clear log file命令.且LGWR正需要切換到被清空的日志文件.等待時間是1秒.很少見。
5. log file switch (private strand flush incomplete)
很少見。
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIke 'log file sync';
在V$SESSION_WAIT這個視圖裡面，這個等待事件有三個參數P1、P2、P3，其中P1為buffer#代表在日志緩沖區中需要被寫入到重做日志文件中的緩存的數量，即redo buffer 中需要被寫入到磁盤中的buffer。寫入的同時會確認事務是否已經被提交，並且保留提交信息到實例意外中斷之前，因此必須等待LGWR將P1數量的緩存寫入重做日志文件為止。P2、P3屬於無用的參數。
更多請參考metalink：1626301.1，地址：http://blog.itpub.net/26736162/viewspace-2124856/
英文版：Troubleshooting: 'Log file sync' Waits (文檔 ID 1376916.1)
此等待事件用戶發出提交或回滾聲明後,等待提交完成的事件,提交命令會去做日志同步,也就是寫日志緩存到日志文件， 在提交命令未完成前,用戶將會看見此等待事件,注意,它專指因提交,回滾而造成的寫緩存到日志文件的等待.當發生此等待事件時,有時也會伴隨log file parallel write.因為此等待事件將會寫日志緩存，如果日志的I/O系統較為緩慢的話,這必將造成log file parallel write 等待.當發生log file sync等待後,判斷是否由於緩慢的日志I/O造成的,可以查看兩個等待事件的等待時間,如果比較接近,就證明日志I/O比較緩慢或重做日志過多,這時,造成log file sync的原因是因為log file parallel write,可以參考解決log file parallel write的方法解決問題,如果log file sync的等待時間很高,而log file parallel write的等待時間並不高,這意味著log file sync的原因並不是緩慢的日志I/O,而是應用程序過多的提交造成的.
當一個用戶提交或回滾數據時，LGWR將會話期的重做由日志緩沖區寫入到重做日志中，LGWR完成任務以後會通知用戶進程。日志文件同步過程（Log File Sync）必須等待這一過程成功完成。對於回滾操作，該事件記錄從用戶發出Rollback命令道回滾完成的時間。如果該等待過多，可能說明LGWR的寫出效率低下，或者系統提交過於頻繁。針對該問題，可以通過log file parallel write等待事件或User Commits、User Rollback等統計信息來觀察提交或回滾次數。
這是一個用戶會話行為導致的等待事件，當一個會話發出一個commit命令時，LGWR進程會將這個事務產生的redo log從log buffer裡面寫到磁盤上，以確保用戶提交的信息被安全地記錄到數據庫中。
當一個用戶會話提交，會話的重做信息需要從內存刷新到重做日志文件，使其永久化。
這個等待事件是指等待Oracle的前台的COMMIT和ROLLBACK操作進程完成，有時候這個等待事件也會包括等待LGWR進程把一個會話事務的日志記錄信息從日志緩沖區中寫入到磁盤上的重做日志文件中。因此，當前台進程在等待這個事件的時候，LGWR進程同時也在等待事件log file parallel write。理解什麼造成這個等待事件的關鍵在於對比這個等待事件和log file parallel write等待事件的平均等待時間：如果它們的等待時間差不多，那麼就是重做日志文件的I/O引起了這個等待事件，則需要調整重做日志文件的I/O，這個在之後會有詳細的講述。如果log file parallel write等待事件的平均等待時間明顯小於log file sync等待事件的等待時間，那麼就是一些其他的寫日志的機制在COMMIT和ROLLBACK操作的時候引起了等待，而不是I/O引起的等待，例如重做日志文件的latch的競爭，會伴隨著出現latch free或者LGWR wait for redo copy等待事件。
在提交時，用戶會話會通知 LGWR 把日志緩沖區中的信息寫到重做日志文件（當前所有未被寫入磁盤的 redo 信息，包括本次會話的 redo 信息）。當 LGWR 完成寫操作後，它會通知用戶會話。當等待 LGWR 通知確認所有 redo 已經安全的保存到磁盤的過程時，用戶會話會等待'log file sync'。
用戶會話顯示等待'log file sync'，是用戶會話通知 LGWR 和 LGWR 通知用戶的寫操作完成之間的時間。
需要注意的是，如果已有一個正在進行的同步，其他需要提交的會話（為了保存日志信息）也需等待 LGWR，進而也將等待'log file sync'？
當系統中出現大量的log file sync等待事件時，應該檢查數據庫中是否有用戶在做頻繁的提交操作。這種等待事件通常發生在OLTP系統上。 OLTP 系統中存在很多小的事務，如果這些事務頻繁被提交，可能引起大量的log file sync的等待事件。
如果這個等待事件在整個等待時間中占了比較大的比重，可以從以下幾個方面來調整這個等待事件：
1).調整LGWR進程使其具有更好的磁盤I/O吞吐量，盡量使用快速磁盤，不要把redo log file存放在RAID5的磁盤上；RAID5 對於頻繁寫入得系統會帶來較大的性能損失，可以考慮使用文件系統直接輸入/輸出，或者使用裸設備(raw device)，這樣可以獲得寫入的性能提高。
2). 使用批量提交 如果存在很多執行時間很短的事務，可以考慮將這些事務集合成一個批處理事務以減少提交的次數，因為每次提交都需要確認相關的日志寫入重做日志文件，因此使用批處理事務來減少提交的次數是一種非常行之有效的減少I/O的方法。
3). 適當使用NOLOGGING/UNRECOVERABLE等選項，查看是否一些操作可以安全的使用NOLOGGING或者UNRECOVERABLE選項，這樣可以減少日志的產生。
用戶應該搜集那些信息，來初步分析'log file sync'等待事件？
初步分析等待'log file sync'，下面的信息是有幫助的：
l 沒有'log file sync'等待的類似時間的 AWR 報告，作為用於比較的性能基線
l 'log file sync'等待發生期間的 AWR 報告 注：2 個報告應在 10-30 分鐘之間。
l LGWR 日志文件 當'log file parallel wait'高的時候，LGWR 日志文件將會顯示警告信息
什麼原因造成了很高的’log file sync’等待？
‘log file sync’可以在用戶會話通知 LGWR 寫日志，和 LGWR 寫完日志後通知用戶會話，及用戶會話被喚醒間的任何一個點發生。
更多詳情，請參照文檔:
Document:34592.1 WAITEVENT: "log file sync"
其中的最常見的原因：
Ø 影響 LGWR 的 I/O 性能問題
Ø 過多的應用程序 commit
這些原因以及如何解決它們詳情概述如下：
影響 LGWR 的 IO 性能問題
我們在這裡回答的主要問題是“是否 LGWR 寫入磁盤慢？”,下面的步驟可以幫助確定是否是這個導致的。
比較'log file sync'和'log file parallel write'的平均等待時間。
等待事件'log file parallel write'表示 LGWR 正在等待寫 redo 操作。該事件的持續時間就是等待 IO 操作部分的時間。關於'log file parallel write'的更多信息，請參閱:
Document:34583.1 WAITEVENT: "log file parallel write" Reference Note
結合事件“log file sync”看同步操作消耗在 IO 的時間，由此推斷，有多少處理時間消耗在 CPU 上。
上面的例子顯示了'log file sync' 和 'log file parallel write' 都有很高的等待時間
如果'log file sync'的時間消耗在'log file parallel write'上的比例高，那麼大部分的等待時間是由於 IO（等待 redo 寫入）。應該檢查 LGWR 在 IO 方面的性能。作為一個經驗法則，'log file parallel write'平均時間超過 20 毫秒, 意味著 IO 子系統有問題。
建議：
1. 與系統管理員一起檢查重做日志所在的文件系統的位置，以提高 IO 性能。
2. 不要把重做日志放在需要額外計算的RAID上，比如 RAID-5或者RAID-6
3. 不要把重做日志放在 Solid State Disk (SSD)
雖然通常情況下，SSD 寫入性能好於平均水平，他們可能會遇到寫峰值,從而導致大量的增加'log file sync'等待(關於這一點您需要詳盡的測試，因為我們也碰到一些SSD的性能可以接受的系統)
(Engineered Systems (Exadata, SuperCluster 和 Oracle Database Appliance) 除外，因為在這些系統上已經為使用SSD來存放重做日志而做了額外的優化)
4. 監控其他可能需要寫到相同路徑的進程，確保該磁盤具有足夠的帶寬，足以應付所要求的容量。如果不能滿足,移動這些進程或 redo。
5. 確保 LOG_BUFFER 不要太大，一個非常大的 log_buffer 的不利影響就是刷新需要更長的等待時間。當緩沖區滿了的時候，它必須將所有數據寫入到重做日志文件。LGWR 將一直等待,直到最後的 I/O 完成。
間歇性物理IO緩慢對 'log file sync' 等待事件的影響：
LGWR傾向於做很多小的IO操作，而不是大塊的IO操作。大部分的磁盤配置並不能在這種場景下很好的工作，可能會發生間歇性物理IO緩慢。但是從平均等待時間來看，IO等待的時間並不長，磁盤設備提供商據此斷定沒有磁盤問題。 因為系統裡還有其它的IO操作，所有這些正常的IO操作的等待時間很短，所有這些IO操作平均起來的等待時間並不長，這就掩蓋了間歇性物理IO緩慢的問題。 但是間歇性物理IO緩慢的問題會造成很高的'log file sync', 雖然平均的'log file parallel write'是處於正常性能的范圍
如果你發現系統的'log file sync'很高，但是'log file parallel write'是處於正常的范圍，那麼這可能是由於間歇性物理IO緩慢導致的。你需要使用一些像OSWatcher一樣的工具(參照 Document 301137.1)來確定是否系統中存在間歇性物理IO緩慢。如果可以確定存在間歇性物理IO緩慢, 那麼你需要與磁盤提供商一起來解決這個問題。
檢查 LGWR trace
盡管'log file parallel write'的平均等待時間可能在一個合理的區間范圍內，在峰值時刻寫操作時間還是可能會很長進而影響’log file sync’的等待時間。從10.2.0.4 開始如果寫操作超過 500 毫秒我們會在 LGWR 的 trace 中寫警告信息。這個閥值很高所以就算沒有警告也不代表沒有問題。警告信息如下：
*** 2011-10-26 10:14:41.718
Warning: log write elapsed time 21130ms, size 1KB
(set event 10468 level 4 to disable this warning)
*** 2011-10-26 10:14:42.929
Warning: log write elapsed time 4916ms, size 1KB
(set event 10468 level 4 to disable this warning)
注意：上面的峰值如果時間間隔的很遠,可能不會對'log file parallel wait'有大的影響。 但是，如果有 100 個會話等待'log file parallel wait'完成，'log file sync'總等待可能就會很高，因為等待時間將被乘以會話的個數 100。因此，值得探討日志寫 IO 高峰的原因。
請參閱：
Document:601316.1 LGWR Is Generating Trace file with "Warning: Log Write Time 540ms, Size 5444kb" In 10.2.0.4 Database
建議：
與系統管理員一起檢查其他正在發生的可能會導致 LGWR 寫磁盤峰值的操作
當 LGWR 進程慢的時候，對其進行 Truss 操作會幫助確定時間消耗在什麼地方
注意：這些警告信息對於預防潛在問題的發生很有幫助。就算平均等待時間沒問題，通過找到 I/O 性能峰值點，DBA 可以知道 LGWR 會間歇性的遇到性能問題，進而在它引發更大問題前將其解決。
檢查在線重做日志是否足夠大
每次重做日志切換到下一個日志時，會執行'log file sync'操作，以確保下一個日志開始之前信息都寫完。 標准建議是日志切換最多 15 至 20 分鐘一次。 如果切換比這更頻繁，那麼將發生更多的'log file sync'操作，意味著更多的會話等待。
檢查 alert.log 日志文件切換的時間
Thu Jun 02 14:57:01 2011
Thread 1 advanced to log sequence 2501 (LGWR switch)
Current log# 5 seq# 2501 mem# 0: /opt/oracle/oradata/orcl/redo05a.log
Current log# 5 seq# 2501 mem# 1: /opt/oracle/logs/orcl/redo05b.log
Thu Nov 03 14:59:12 2011
Thread 1 advanced to log sequence 2502 (LGWR switch)
Current log# 6 seq# 2502 mem# 0: /opt/oracle/oradata/orcl/redo06a.log
Current log# 6 seq# 2502 mem# 1: /opt/oracle/logs/orcl/redo06b.log
Thu Nov 03 15:03:01 2011
Thread 1 advanced to log sequence 2503 (LGWR switch)
Current log# 4 seq# 2503 mem# 0: /opt/oracle/oradata/orcl/redo04a.log
Current log# 4 seq# 2503 mem# 1: /opt/oracle/logs/orcl/redo04b.log
在上面的例子中，我們看到每 2 到 4 分鐘進行日志切換，這比建議值的5倍還高。
您也可以檢查 AWR 報告日志切換的平均時間
在上面的例子中基於 AWR 中的信息，每小時有 29.98 次重做日志切換：每 2 分鐘切換一次。這個比每 15-20 分鐘切換一次的建議值要高,並將影響前台進程需要等待'log file sync'完成的時間，因為發起同步操作的開銷比必要的多。
建議：增加redo logs的大小
Document:602066.1 How To Maintain and/or Add Redo Logs
Document:779306.1 How To Add/Increase The Size Of Redo Log Files In Rac Environment?
應用程序提交過多
在這種情況下，要回答的問題是“是否應用程序 commit 過於頻繁？ ”。
如果是，那麼過多的 commit 活動可能會導致性能問題，因為把 redo 從日志緩沖區刷新到重做日志可能會導致等待'log file sync'。
如果’log file sync’的平均等待時間比’log file parallel write’高很多，這意味著大部分時間等待不是由於等待 redo 的寫入，因而問題的原因不是 IO 慢導致。 剩余時間是 CPU 活動，而且是過多的 commit 導致的最常見的競爭。
此外，如果'log file sync'的平均等待時間低，但等待次數高，那麼應用程序可能 commit 過於頻繁。
比較 user commit/rollback 同 user calls 比值的平均值：
在 AWR 或 Statspack 報告中，如果每次 commit/rollback 的平均 user calls（"user calls/(user commits+user rollbacks)"） 小於 30， 表明 commit 過於頻繁
在上面的例子中，我們看到，平均每 5.76 次 user calls 就會有一次 commit, 大約高出建議值 5 倍。基於經驗，我們期望 user calls/user commit 至少是 25。當然，這取決於應用程序。
建議：
如果有很多短事務，看是否可能把這些事務組合在一起，從而減少 commit 操作。 因為每一個 commit 都必須收到相關 REDO 已寫到磁盤上的確認，額外的 commit 會顯著的增加開銷。雖然 Oracle 可以將某些 commit 組合在一起，通過事務的批處理來減少commit的總體數量還是可以帶來非常有益的效果。
看看是否有操作可以使用 COMMIT NOWAIT 選項 （務必在使用前應明白語義）。
看看是否有操作可以安全地使用 NOLOGGING/ UNRECOVERABLE 選項完成。
其他可能相關的等待事件：
檢查 AWR 報告，看是否有跟 LGWR 相關的,顯示占用了顯著數量時間的其他事件,因為這可能會給出導致這個問題的一個線索。前台和後台事件都應該進行檢查。
例如下面的 AWR 顯示某些其他前台和後台等待事件等待高，意味著傳輸重做日志到遠程位置的問題，這可能會導致 fore gorund 進程等待"log file sync"。
Adaptive Log File Sync
11.2 中引入了 Adaptive Log File sync，由參數 _use_adaptive_log_file_sync 控制，在 11.2.0.1 和 11.2.0.2 默認設置為 false。
從 11.2.0.3 開始默認是 true。 當啟用時，Oracle 可以在兩種方法之間切換：
Post/wait，傳統發布寫重做日志完成的方法
Polling，一種新的方法，其中前台進程會檢查 LGWR 是否已寫完成。
更多關於這個特性的信息，請參閱:
Document 1541136.1 Waits for "log file sync" with Adaptive Polling vs Post/Wait Choice Enabled
Redo Synch Time Overhead：
統計值'redo synch time overhead'在11.2.0.4和12c被引入，記錄了理想的log file sync時間以及真正的log file sync時間的差值。
如果這個差值很小，說明log file sync等待次數可能是log file parallel write等待之外的原因導致的
當一個用戶提交或回滾數據時，LGWR將會話期的重做由Log Buffer寫入到重做日志中，
LGWR完成任務以後會通知用戶進程。日志文件同步等待（Log File Sync）就是指進程等待
LGWR寫完成這個過程；對於回滾操作，該事件記錄從用戶發出rollback命令到回滾完成的時
間。
如果該等待過多，可能說明LGWR的寫出效率低下，或者系統ᨀ交過於頻繁。針對該問
題，可以關注log file parallel write等待事件，或者通過user commits,user rollback等統計信息
觀察ᨀ交或回滾次數。
可能的解決方案主要有：
l ᨀ高LGWR性能，盡量使用快速磁盤，不要把redo log file存放在RAID5的磁盤上；
l 使用批量ᨀ交；
l 適當使用NOLOGGING/UNRECOVERABLE等選項。
可以通過如下公式計算平均Redo寫大小：
avg.redo write size = (Redo block written/redo writes)*512 bytes
如果系統產生Redo很多，而每次寫的較少，一般說明LGWR被過於頻繁地激活了。可
能導致過多的Redo相關Latch的競爭，而且Oracle可能無法有效地使用piggyback的功能。
從一個Statspack報告中ᨀ取一些數據來研究一下這個問題。
Report概要信息如下：
DB Name DB Id Instance Inst Num Release OPS Host
------------ ----------- ------------ -------- ----------- --- ------------
DB 1222010599 oracle 1 9.1.7.4.5 NO sun
Snap Id Snap Time Sessions
------- ------------------ --------
Begin Snap: 3473 13-Oct-04 13:43:00 540
End Snap: 3475 13-Oct-04 14:07:28 540
Elapsed: 24.47 (mins)
Cache Sizes
~~~~~~~~~~~
db_block_buffers: 102400 log_buffer: 20971520
db_block_size: 8192 shared_pool_size: 600M
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 28,459.11 2,852.03
等待事件如下：
Event Waits Timeouts Time (cs) (ms) /txn
---------------------------- ------------ ---------- ----------- ------ ------
log file sync 14,466 2 4,150 3 1.0
db file sequential read 17,202 0 2,869 2 1.2
latch free 24,841 13,489 2,072 1 1.7
direct path write 121 0 1,455 120 0.0
db file parallel write 1,314 0 1,383 11 0.1
log file sequential read 1,540 0 63 0 0.1
log file switch completion 1 0 3 30 0.0
refresh controlfile command 23 0 1 0 0.0
LGWR wait for redo copy 46 0 0 0 0.0
log file single write 4 0 0 0 0.0
注意以上輸出信息，這裡log file sync和db file parallel write等等待事件同時出現，那麼
可能的一個原因是I/O競爭導致了性能問題，實際用戶環境正是日志文件和數據文件同時存放
在RAID5的磁盤上，存在性能問題需要調整。
統計信息如下：
Statistic Total per Second per Trans
--------------------------------- ---------------- ------------ ------------
……
redo blocks written 93,853 63.9 6.4
redo buffer allocation retries 1 0.0 0.0
redo entries 135,837 92.5 9.3
redo log space requests 1 0.0 0.0
redo log space wait time 3 0.0 0.0
redo ordering marks 0 0.0 0.0
redo size 41,776,508 28,459.1 2,852.0
redo synch time 4,174 2.8 0.3
redo synch writes 14,198 9.7 1.0
redo wastage 4,769,200 3,249.8 325.6
redo write time 3,698 2.5 0.3
redo writer latching time 0 0.0 0.0
redo writes 14,572 9.9 1.0
……
sorts (disk) 4 0.0 0.0
sorts (memory) 179,856 122.5 12.3
sorts (rows) 2,750,980 1,874.0 187.8
……
transaction rollbacks 36 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
user calls 1,390,718 947.4 94.9
user commits 14,136 9.6 1.0
user rollbacks 512 0.4 0.0
write clones created in backgroun 0 0.0 0.0
write clones created in foregroun 11 0.0 0.0
-------------------------------------------------------------
根據統計信息可以計算平均日志寫大小：
avg.redo write size = (Redo block written/redo writes)*512 bytes
= ( 93,853 / 14,572 )*512
= 3KB
這個平均值過小了，說明系統的ᨀ交過於頻繁。從以上的統計信息中，可以看到平均每
秒數據庫的ᨀ交數量是9.6次。如果可能，在設計應用時應該選擇合適的ᨀ交批量，從而ᨀ高
數據庫的效率。
Latch Sleep breakdown for DB: DPSHDB Instance: dpshdb Snaps: 3473 -3475
-> ordered by misses desc
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
-------------------------- -------------- ----------- ----------- ------------
row cache objects 12,257,850 113,299 64 113235/64/0/0/0
shared pool 3,690,715 60,279 15,857 52484/588/6546/661/0
library cache 4,912,465 29,454 8,876 23823/2682/2733/216/0
cache buffers chains 10,314,526 2,856 33 2823/33/0/0/0
redo writing 76,550 937 1 936/1/0/0/0
session idle bit 2,871,949 225 1 224/1/0/0/0
messages 107,950 159 2 157/2/0/0/0
session allocation 184,386 44 6 38/6/0/0/0
checkpoint queue latch 96,583 1 1 0/1/0/0/0
-------------------------------------------------------------
由於過度頻繁的ᨀ交，LGWR過度頻繁的激活，看到這裡出現了redo writing的latch 競
爭。
以下是一則ASH報告中顯示的Log File Sync等待信息，注意到其Parameter 1是Buffer#，
Parameter 2代表Sync SCN，也就是同步的SCN。Log File Sync以SCN為節點，以Buffer號
為起始，不斷將Log Buffer的內容寫出到日志文件上來：
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIke 'log file parallel write';
這個等待事件有三個參數：
Files： 操作需要寫入的文件個數。
Blocks： 操作需要寫入的數據塊個數。
Requests：操作需要執行的I/O次數
在V$SESSION_WAIT這個視圖裡面，這個等待事件有三個參數P1、P2、P3，其中P1代表正在被寫入的重做日志文件組中的重做日志文件號，P2代表需要寫入重做日志組中每個重做日志文件的重做日志BLOCK數量，P3代表I/O請求的次數，需要被寫入的BLOCK會被分成多次分別請求。
從Log Buffer寫Redo記錄到日志文件，主要指常規寫操作（相對於Log File Sync）。如果Log Group存在多個組成員，當Flush Log Buffer時，寫操作是並行的，這時候此等待事件可能出現。盡管這個寫操作並行處理，直到所有I/O 操作完成該寫操作才會完成(如果你的磁盤支持異步IO或者使用IO SLAVE，那麼即使只有一個redo log file member,也有可能出現此等待)。後台進程LGWR 負責將log buffer當中的數據寫到REDO 文件中，以重用log buffer的數據。 如果每個REDO LOG組裡面有2個以上的成員，那麼LGWR進程會並行地將REDO 信息寫入這些文件中。
這個等待事件出現在當LGWR後台進程從日志緩沖區寫日志信息到磁盤上的重做日志文件的時候。只有啟用了異步I/O的時候LGWR進程才會並行寫當前日志組內的重做日志文件，否則LGWR只會循環順序逐個的寫當前日志組重做日志文件。LGWR進程不得不等待當前日志組所有的重做日志文件成員全部寫完，因此，決定這個等待事件的等待時間長短的主要因素是重做日志文件所在磁盤的I/O讀寫的速度。
這個參數和log file sync 時間相比較可以用來衡量log file 的寫入成本。通常稱為同步成本率。
如果數據庫中出現這個等待事件的瓶頸，主要的原因可能是磁盤I/O性能不夠或者REDO 文件的分布導致了I/O爭用，比如同一個組的REDO 成員文件放在相同的磁盤上。
如果是當前的LGWR進程寫的速度不夠快導致了這個等待事件，可以通過查看一些和重做日志相關的統計值判定當前的LGWR進程是否效率很低，具體的可以查看"redo writes"、"redo blocks written"、"redo write time"、"redo wastage"、"redo size"統計值，這些都是和LGWR進程性能直接相關的一些統計值。
如果這個等待事件占用的等待時間比較多，可以從以下幾個方面來進行調整：
l 對能使用UNRECOVERABLE/NOLOGGING的操作盡量使用這兩個選項來減少重做日志的產生。
l 在保證不會同時丟失重做日志文件的前提下盡量減少重做日志組中的成員的個數，減少每次寫重做日志組文件的時間。
l 除非在備份的情況下，否則不要在將表空間置於熱備的模式下，因為表空間處於熱備的模式下會產生更多的重做日志文件。
l 對於使用LogMiner、Logical Standby或者Streams，在能夠滿足要求功能的前提下，盡量使用最低級別的追加日志以減少重做日志的產生。
l 盡量將同一個日志組內的重做日志文件分散到不同的硬盤上，減少並行寫重做日志文件的時候產生的I/O競爭。
l 不要將重做日志文件放置在RAID-5的磁盤上，最好使用裸設備來存放重做日志文件。
l 如果設置了歸檔模式，不要將歸檔日志的目的地設置為存放重做日志存放的磁盤上面，避免引起I/O競爭。
當日志緩存到日志文件時,這是一個主要的等待事件.雖然這個時間的名字中有"並行"(parallel)字樣,但即使日志緩存並沒有使用並行寫,因日志緩存的寫出而造成的等待仍然是此等待事件.
我們可以通過v$system_event來了解下某一個階段內,此等待事件的平均等待時間.通過此時間值,來評估我們的日志I/O是否正常.有資料介紹當log file parallel write的平均等待時間大於10毫秒時.有可能就表明著日志的吞吐量緩慢.我認為這只是一個參考值,在不同的系統上要根據不同的情況來決定.記錄一些在正常情況下log file parallel write等待事件的平均等待時間,當出現問題後,以此時間作為是否有問題的標准.這種方法也是可取的.
當日志I/O確實有問題時,減少重做產生的數量,確實能夠緩解log file parallel write的等待時間.但有時,重做信息的數量是無法減少的.根據情況,將日志I/O轉移到更快速的磁盤上,也是解決問題的方法之一.
日志緩存的大小,有時候也會對此等待事件產生影響.如果你的日志緩存更大,會降低LGWR刷新緩存到磁盤的次數,增大日志的緩存,也會有助於緩解此等待事件.但過大的日志緩存,有可能會造成LGWR間歇性的擁堵.因為LGWR被觸發的條件之一是日志緩存滿1/3,如果日志緩存過大,1/3的日志緩存數量可能過多,每次LGWR被觸發,不得不寫大量數據,這造成LGWR間歇性的停頓與擁堵,這也會增加此等待事件的等待時間.我們可以通過設置隱藏參數_log_io_size來改變日志緩存滿1/3才觸發LGWR的阙值.通過設置此參數,我們即可以擁有較大的日志緩存,又避免了LGWR間歇性的停頓或擁堵.
我沒有在生產庫中使用過這個參數,因為他畢竟是一個隱藏參數.雖然據說他不會帶來什麼bug.在我的測試機上,通過調節這個參數,確實可以對性能略有提升.但這些都是為數據庫的"微調".不可能帶來大幅度的性能提升.
LGWR 在刷新緩存時,需要redo allocation和redo writing闩,並且LGWR需要等待一些redo copy 闩的完成.因此,如果這些闩的爭用較高,則不要減少_log_io_size此隱藏參數,因為減少它,將會使LGWR更為頻繁的刷新緩存.這會進一步加劇這3個闩的爭用.減緩LGWR完成工作的速度.
**小小結:日志緩存到底應該設置為多大??_log_io_size參數的值應該定為多少??這沒有一個統一的標准,只有通過多做測試才能決定.
從log buffer寫Redo記錄到日志文件，主要指常規寫操作（相對於log file sync）。如果每
個日志組存在多個組成員，當flush log buffer時，寫操作是並行的，這時此等待事件可能出現。
盡管這個寫操作並行處理，直到所有I/O操作完成該寫操作才會完成（如果磁盤支持異步
IO或者使用IO SLAVE，那麼即使只有一個redo log file member，也有可能出現此等待）。這
個參數和log file sync時間相比較可以用來衡量log file的寫入成本，通常稱為同步成本率。
當數據庫產生日志的速度比LGWR的寫出速度快，或者是當日志切換（log switch）太慢
時，就會發生這種等待。這個等待出現時，通常表明redo log buffer過小，為解決這個問題，
可以考慮增大日志文件的大小，或者增加日志緩沖區的大小。
另外一個可能的原因是磁盤I/O存在瓶頸，可以考慮使用寫入速度更快的磁盤。在允許的條件下，可以考慮使用裸設備來存放日志文件，ᨀ高寫入效率。在一般的系統中，最低的標准是，不要把日志文件和數據文件存放在一起，因為通常日志文件只寫不讀，分離存放可以獲得性能ᨀ升，盡量使用RAID10而不是RAID5磁盤來存儲日志文件。以下是一個log buffer存在問題的Statspack Top5等待事件的系統：
Top 5 Wait Events
~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write 1,436,993 1,102,188 10.80
log buffer space 16,698 873,203 9.56
log file sync 1,413,374 654,587 6.42
control file parallel write 329,777 510,078 5.00
db file scattered read 425,578 132,537 1.30
-------------------------------------------------------------
Log Buffer Space等待事件出現時，數據庫將陷於停頓狀態，所有和日志生成相關的操作全部不能進行，所以這個等待事件應該引起充分的重視。
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIke 'log buffer space';
當數據庫產生日志的速度比LGWR的寫出速度快，或者當日志切換太慢時，就會發生這種等待。這個等待出現時，通常表明Redo log buffer過小，為解決這個問題，可以考慮增大日志文件的大小或者增加日志緩沖器的大小。
另一個可能的原因是磁盤I/O存在瓶頸，可以考慮使用寫入速度更快的磁盤。在允許的條件下設置，可以考慮使用裸設備來存放日志文件，提高寫入效率。在一般的系統中，最低的標准是，不要把日志文件和數據文件存放在一起，因為通常日志文件只寫不讀，分離存放可以獲得性能提升，盡量使用RAID10而不是RAID5磁盤來存儲日志文件。當log buffer 中沒有可用空間來存放新產生的redo log數據時，就會發生log buffer space等待事件。 如果數據庫中新產生的redo log的數量大於LGWR 寫入到磁盤中的redo log 數量，必須等待LGWR 完成寫入磁盤的操作，LGWR必須確保redo log寫到磁盤成功之後，才能在redo buffer當中重用這部分信息。
如果數據庫中出現大量的log buffer space等待事件，可以考慮如下方法：
（1） 增加redo buffer的大小。
（2） 提升磁盤的I/O性能
服務器進程生成重做記錄的速度快過LGWR寫出重做記錄的速度,因而發生等待.日志I/O緩慢是log buffer space等待的主要原因之一.還有一點,如果日志緩存區過小,也容易出現此等待事件.將日志緩存設置的大一些,對於緩解此事件的等待會有幫助.但是,過大的日志緩存,又會降低LGWR刷新緩存的頻率,這可能會使提交時必須刷新的緩存數量增多.從而造成log file sync等待.日志緩存具體應該設置為多大,這就多進行測試咯.不同的環境下,不可能有一個標准.為了緩解log buffer space等待事件,將日志緩存調節的比較大之後,可以通過_log_io_size參數來提高LGWR刷新緩存的頻率.這樣做既可以減少log buffer space的等待,也可以減少log file sync等待.但這樣的隱藏參數 應該小心使用.
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE 'log file sequential read';
Waiting for the read from this logfile to return. This is used to read redo records from the log file.
這個等待事件包含三個參數：
Log#： 發生等待時讀取的redo log的sequence號。
Block#： 讀取的數據塊號。
Blocks： 讀取的數據塊個數。P3的值為1，一般來說都是在讀取日志文件頭。
SELECT SEGMENT_NAME, SEGMENT_TYPE, OWNER, TABLESPACE_NAME
FROM DBA_EXTENTS
WHERE FILE_ID = FILE#
AND BLOCK# BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;
這個等待事件通常發生在對redo log信息進行讀取時，比如在線redo的歸檔操作，ARCH進程需要讀取redo log的信息，由於redo log的信息是順序寫入的，所以在讀取時也是按照順序的方式來讀取的。
這個等待事件是指等待讀取重做日志文件中的日志記錄，等待的時間就是耗費在完成整個讀取日志記錄的物理I/O操作的時間。
等待從日志文件中讀,一般ARC進程會遭遇此事件,如果P3參數為1,證明等待發生在讀日志文件頭,否則,P3代表要讀出的日志塊的數量.
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE 'log file single write';
這個等待事件包含三個參數：
Log#： 正在被寫入的重做日志文件組的組號。
Block#：寫入的數據塊號。
Blocks：寫入的數據塊個數。
這個等待事件是指等待寫重做日志文件操作完成，常常是在等待寫重做日志文件頭，例如在增加一個新的重做日志組成員的時候，Oracle數據庫就會往這個重做日志文件頭寫入相應的sequence號。
這個等待事件發生在更新redo log文件的文件頭時，當為日志組增加新的日志成員時或者redo log的sequence號改變時，LGWR 都會更新redo log文件頭信息。
因為single write通常都是在寫或者重寫日志文件頭的時候出現，因此開始的block號總是為1。一般如果出現這個等待事件，應該對重做日志文件盡量使用裸設備，避免將多個日志文件放在同一個磁盤上，減少產生I/O競爭的可能。
日志文件寫等待,注意,這裡所指的寫,並不是從日志緩存寫到日志文件,這裡的寫並不涉及日志緩存,此事件只代表寫日志文件頭時發生的等待.有兩種情況日志文件頭被寫:當添加新的成員文件或日志序列號增加.應對日志文件盡量使用裸設備.或避免將日志文件放在同一磁盤上,以減少此事件產生的可能。
該事件僅與寫日志文件頭塊相關，通常發生在增加新的組成員和增進序列號（Log switch）時。頭塊寫單個進行，因為頭塊的部分信息是文件號，每個文件不同。更新日志文件頭這個操作在後台完成，一般很少出現等待，無需太多關注。
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE '%LGWR wait for redo copy%';
LGWR將要寫一組日志塊,但它必須等待直到服務器進程完成任意當前的拷貝操作,這些拷貝操作影響將要被寫出的緩存。
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE '%switch logfile command%';
執行日志文件切換命令的時候等待日志文件切換完成.超時時間為5秒.
SELECT * FROM V$EVENT_NAME A WHERE A.NAME LIKE '%log switch/archive%';
當DBA手動輸入命令alter system archive log change<SCN>時,可能會等待此事件.
About Me
...............................................................................................................................
● 本文作者：小麥苗，只專注於數據庫的技術，更注重技術的運用
● 本文在itpub（http://blog.itpub.net/26736162）、博客園(http://www.cnblogs.com/lhrbest)和個人微信公眾號（xiaomaimiaolhr）上有同步更新
● 本文itpub地址：http://blog.itpub.net/26736162/viewspace-2125065/
● 本文博客園地址：http://www.cnblogs.com/lhrbest/p/5878100.html
● 本文pdf版：http://yunpan.cn/cdEQedhCs2kFz （提取碼：ed9b）
● 小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/
● QQ群：230161599 微信群：私聊
● 聯系我請加QQ好友(642808185)，注明添加緣由
● 於 2016-09-13 10:00~ 2016-09-17 11:20 在公寓完成
● 文章內容來源於小麥苗的學習筆記，部分整理自網絡，若有侵權或不當之處還請諒解！
● 【版權所有，文章允許轉載，但須以鏈接方式注明源地址，否則追究法律責任】
...............................................................................................................................
手機長按下圖識別二維碼或微信客戶端掃描下邊的二維碼來關注小麥苗的微信公眾號：xiaomaimiaolhr,免費學習最實用的數據庫技術。
