本文主要轉載魏興華大師在itpub上的一篇帖子，由於csdn禁止itpub的連結，就不貼了：

log file sycn是ORACLE裡最普遍的等待事件之一，一般log file sycn的等待時間都非常短 1-5ms，不會有什麼問題，但是一旦出問題，往往都比較難解決。什麼時候會產生log file sync等待？
常見有以下幾種：
1)commit操作
2)rollback操作
3)DDL操作（DDL操作實施前都會首先進行一次commit）
4)DDL操作導致的資料字典修改所產生的commit
5)某些能遞迴修改資料字典的操作：比如查詢SEQ的next值，可能會導致修改資料字典。一個典型的情況是，SEQ的cache屬性設定為nocache，那麼會導致每次呼叫SEQ都要修改資料字典，產生遞迴的commit。

一個正常的系統裡，絕大多數的log file sycn等待都應該是上面描述的1）commit操作 造成的log file sycn等待，某些異常的系統，比如頻頻rollback、seq的cache設定為nocache的系統，也可能會造成比較多的log file sycn等待。

當user發出commit或rollback語句時會觸發LGWR將重做記錄寫入redo log，這種觸發LGWR的方式叫做同步寫（sync writes）觸發，而其他剩下的觸發LGWR的方式叫做後臺寫（background writes）。log file sync等待事件只與sync writes有關，而log file parallel write等待事件只與background writes有關

我們要是能知道log file sync包含哪些環節，再有針對性的優化各個環節，就能事半功倍了。

上面是Tanel Ponder畫的log file sync等待事件的延遲圖，在某些關鍵環節上打了點。我對其中打點的環節，稍作翻譯如下：
1)使用者程序發起commit
2)使用者程序通知lgwr寫日誌
3)lgwr接收到請求開始寫
4)lgwr寫完成
5)lgwr通知使用者程序寫完成
6)使用者程序獲得通知，繼續做其他事

1,2階段的時間，主要是post/wait的時間，典型的這種post/wait一般利用的是作業系統的訊號量（IPC)實現，如果系統CPU資源充足，一般不會出現大的延遲。前臺程序post lgwr後，就開始等待log file sync。
2,3階段的時間，主要是lgwr為了獲取cpu資源，等待cpu排程的時間，如果系統cpu資源充足，一般不會出現大的延遲。這裡我們需要知道，lgwr只是作業系統的一個程序，它需要作業系統的排程獲取cpu資源後才可以工作
3,4階段的時間，主要是真正的物理io時間，lgwr通知os把log buffer的內容寫入到磁碟，然後lgwr進入睡眠（等待log file parallel write），這個時間正常情況下的延遲佔整個log file sync的大部分時間。還需要指出，lgwr在獲取cpu資源後，可能並不能馬上通知os寫磁碟，只有在確保所有的redo copy latch都已經被釋放，才能開始真正的IO操作。
4,5階段的時間，os排程lgwr 重新獲得cpu資源，lgwr post前臺程序寫完成。lgwr可能會post很多前臺程序(group commit的副作用)
5,6階段的時間，前臺程序接受到lgwr的通知，返回cpu執行佇列，處理其他事物（log file sync結束）。

/*************************************************什麼是group commit************************************************/
不止一次的看到過一些對log file sync調優的建議裡寫著：開啟ORACLE的組提交功能。
group commit預設就是開啟的，而且你沒有任何手段可以關閉它!
我一直認為group commit這個東東起的名字不是太過恰當，應該起組重新整理更恰當，僅僅代表個人意見。
什麼是組提交？

上圖是log buffer的抽象圖，log buffer此時是非常繁忙的。
給大家設定這樣一個場景。
c1作為一個commit record已經被copy到了log buffer裡，接著前臺程序通知lgwr去寫日誌，根據我前面的描述，在前臺程序post lgwr去寫，到lgwr真正開始寫之前，非常可能存在著時間差，就在這個時間差裡，c2,g1,c3也已經把相應的日誌拷貝到了log buffer裡，其中c1,c2,c3是commit的記錄，g1僅僅是普通的事務日誌，不是commit日誌。在lgwr真正開始寫之前，它會去檢查當前log buffer的最高點，發現在c3位置處，把這個點作為此次重新整理日誌的目標，把c1,c2,g1,c3的日誌都重新整理到磁碟。雖然重新整理日誌這個操作是由c1出發的，但是c2,g1,c3也是受惠者搭了便車，日誌也被重新整理到了日誌檔案裡，這個功能叫組提交，對於一些不太熟悉ORACLE的人容易把組提交誤解為，把提交的事物打包重新整理到日誌裡，其實LGWR是不管你的事務日誌有沒提交的，它只按照log buffer分配的最高點來重新整理，因此我覺得叫組重新整理更好點。
圖中c1,c2,g1的日誌已經拷貝完成，我用filled表示，c3的日誌空間已經分配，但是還沒完成拷貝，我用allo表示，這個情況下，其實lgwr需要等待c3日誌拷貝完成，才能真正的開始重新整理操作。
/*************************************************什麼是group commit************************************************/

我們剖析了log file sycn的各個階段後，可以看出，正常情況下，最慢的環節應該在3,4階段（如上圖），典型的io操作，這個環節對應的資料庫等待叫做log file parallel write。其他的階段如排程延遲、IPC時間一般都是極短的。網上、論壇上、包括不少書籍裡，很多在log file sync出現問題後，往往都把責任推卸到IO慢的原因上。絕大多數情況下，這樣的推斷可能都是正確的，但是，事情不總是這樣的，就像我們分析的，log file sync的快慢也是很依賴cpu資源是否富足、系統的負載是不是過大。我們再看下一幅圖，這副圖描述了，在CPU資源不足的情況下，各個階段佔取整個log file sycn的比重。

LOG FILE SYNC調優
作為通用的log file sync的診斷、調優方法，一般可以通過診斷系統的IO延遲為多大，cpu資源是否充足來判斷哪裡出現了問題。
IO延遲的診斷、調優:可以通過log file parallel write這個後臺程序等待事件來輔助判斷。如果這個等待時間過大，那麼你係統的IO很可能出現了問題。優化IO的手段一般為：RAID的方式不要為RAID5，最好為RAID10，關閉RAID卡的讀CACHE，全部用作寫CACHE，可以用2-4塊盤作為日誌的磁碟組，如果使用的是儲存，一般儲存機頭的CACHE也比較大，IO上基本能得到保障。使用ssd作為日誌組來提升IO並沒有什麼好的效果。可以通過 v$event_histogram檢視獲取log file sycn、log file parallel write等待事件的時間分佈圖（後面有介紹）來輔助診斷。
cpu資源的診斷、調優:如果log file sync的時間與log file parallel write的時間差異過大，則可能系統的CPU資源出現了不足。solaris下還可以通過作業系統工具prstat來診斷lgwr程序的延遲時間，見下圖的LAT列。其他平臺不能直接針對程序進行跟蹤診斷，可以通過系統LOAD，CPU使用率來輔助診斷，如CPU使用率超過百分之六十可能就會造成一定程度的排程延遲、CPU執行佇列超過物理CPU的CORE數就有排程延遲的風險等等。如果系統的CPU資源出現瓶頸是比較棘手的，因為換硬碟尚且還算是執行起來不算費勁的，但是換CPU難度一般會比較大，最終可能的結果就是換主機。不過也有一些手段可以嘗試：調高LGWR的優先順序，可以通過資料庫引數_high_priority_processes進行，或者作業系統命令renice命令進行（前者可能更好點）。調整LGWR優先順序的目的是為了讓LGWR儘可能的容易獲得CPU資源，減少排隊排程時間。
調優應用：不過有時候更為有效的手段可能不是拼命的調優資料庫、調優硬體，比如：是不是可以合併事物，也就降低了LOG FILE SYNC的次數，變相的提高了系統事務的效率。
資料庫調優：通過設定ORACLE的REDO LOG 塊大小為4K來提升日誌寫的效能.11GR2的版本可以指定REDO LOG的塊大小。在我的版本11.2.0.3下修改會報錯，說修改值與實際扇區大小不匹配。通過修改隱含引數_disk_sector_size_override為true，可以強制改成功。修改的辦法是在alter database add log file xxxx blocksize 4096。如果拿PL/SQL壓測，採取commit write immediate wait方式提交，優化前後的差距接近4倍，非常驚人。但是拿我們的業務壓測，只是提升了1500+的TPS，也非常的不錯了。
記憶體調優：在AIX下，如果開啟記憶體預讀，對於提升TPS也是非常的明顯 dscrctl -n -b -s 1 。

/*****************************************************************************可憐的LGWR****************************************************************************/
如果有大量程序在等待LOG FILE SYCN，一旦LGWR寫完成，它將POST這些程序甦醒，使它們重新進入CPU執行佇列，而LGWR會被當初post它寫日誌的程序push off出cpu執行佇列。這個情形下，由於LGWR已經工作了一段時間了（剛剛寫完日誌），而前臺程序已經等待了一段時間了（等待LOG FILE SYNC)，根據作業系統的預設的排程策略，這種情況下，前臺程序將會有更高的優先順序獲取CPU資源，而LGWR將可能由於CPU資源突發式的緊張而沒有獲取到CPU資源，導致系統 的事務數有很大的降低：因為LGWR已經不工作了(雖然時間很短）。因此我前面所建議的調高LGWR程序優先順序的手段是值得嘗試的。
/*****************************************************************************可憐的LGWR****************************************************************************/

獲取log file sync、log file parallel write時間分佈
如果我們僅僅觀察AWR報告，獲取log file sync、log file parallel write某一段時間的平均等待時間，有時候是不夠的，我們可能想更精細化的知道，10000次等待裡，有多少次等待是在1ms以內，有多少次是在2ms以內，等等。查詢V$EVENT_HISTOGRAM可以告訴我們這些資訊，對於我們診斷效能問題非常有幫助。
SQL> select event, wait_time_milli,wait_count
2 from v$event_histogram
3 where event = 'log file parallel write';
EVENT                     WAIT_TIME_MILLI WAIT_COUNT
------------------------- --------------- ----------
log file parallel write                 1      22677
log file parallel write                 2        424
log file parallel write                 4        141
log file parallel write                 8        340
log file parallel write                16       1401
log file parallel write                32        812
log file parallel write                64        391
log file parallel write               128         21
log file parallel write               256          6
如上，我們可以知道log file parallel write等待時間在1ms以內的有22677次，2ms以內的有424次，等等。
我們可以簡單的取兩次V$EVENT_HISTOGRAM的快照，來判斷間隔時間內，指標的變化次數來輔助我們診斷問題。（AWR思想）

LOG BUFFER 需要調優？
一般情況下，是不需要調優的！
10G以後，LOG BUFFER一般情況下已經比較大，一般為1到多個granules大小，除非你看到了比較多的log buffer space等待事件，否則不需要調整log buffer的大小。
9.2以後， LOG BUFFER根據你係統CPU的多少，已經被拆分成多個LOG BUFFER，很大程度上緩解了redo allocatoin latch的爭用，除非看到了明顯的redo allocation latch的爭用，否則不用調整log buffer的數量。
10G以後，私有redo和imu的出現，進一步降低了redo allocation latch的爭用。每一個私有redo都由一個私有的redo allocation latch保護。同上，一般情況不用調整。

redo相關latch需要調優？
redo copy latch：僅僅用來跟蹤是否有程序正在往log buffer裡拷貝資料。lgwr在真正開始寫之前，必須等待相關的程序拷貝完畢，在此期間,lgwr會等待LGWR wait for redo copy等待。可以同時向log buffer裡進行拷貝的程序的數量由_log_simultaneous_copies決定。
redo allocation latch：保護程序在redo buffer裡分配空間用的，保證各個程序間彼此分配的空間不重疊。
redo writing latch：這個latch其實保護的是一個標誌位，程序獲取這個latch後，修改標誌位，比如把0改為1，代表lgwr正在寫，這樣後續的提交程序，獲得這個latch後讀取標誌位，就知道當前LGWR是不是正在寫了，避免了很多不需要的重複通知。
我們知道了這幾個latch的作用，那麼我們需要調優他們嗎？
一般是不需要的，除非他們相關的等待已經引起了你的注意，而且ORACLE各個版本也一直在優化相關的latch的獲取和釋放，比如redo allocation latch，這一塊已經做的非常高效了。

新的調優手段
10GR1的時候，ORACLE公司默默的推出了一個引數：commit_logging，這個引數可以有四種組合：
commit write [batch|immediate][wait|nowait]
10GR2版本釋出的時候，這個引數被拆成了2個引數，commit_logging，commit_write，個人認為10GR2拆分後的引數，更能準確表達引數的意圖。
我們先著重的看下commit_write這個引數，它的引數值可以為wait/nowait，代表：前臺程序事務提交的時候，通不通知LGWR去重新整理日誌。wait為通知，前臺程序會等待log file sync。nowait為不通知，僅僅等待其他操作觸發lgwr去寫日誌（如3秒，1M大小，1/3滿）。如果你的業務對資料的一致性的要求不高，對ACID的D沒有要求，為了提高事物數、提高效能，你可以選擇commit_write為nowait方式。而在10G以前，ACID的D是必須滿足的，也就是說，前臺程序在提交的時候，是必須要等待LOG FILE SYNC，等待LGWR重新整理日誌到磁碟的。
我們來簡單的看下commit_logging引數，引數可以選擇的值有batch/immediate，這個引數極其容易引起人的誤解，讓人誤以為batch的含義是，控制著事物以group commit的方式打包提交。immediate方式是代表讓事物一個個的提交，一次提交重新整理一次log buffer，但是不是這樣的！
immediate與batch相比，commit的改變向量（修改回滾段頭的事務槽）將作為單獨的redo record產生，跟9I的commit記錄日誌的方式是一樣的。batch 模式下commit日誌的記錄方式是合併進事務的redo record裡，這個batch模式依賴使用私有redo和imu，如果他們關閉的情況下，batch的設定也就沒了作用。

我們對insert into a values(1111);commit;來進行dump log file，闡述一下batch/immediate方式的區別 :

DUMP LOG FILE：啟用私有redo和imu，設定commit_logging為immediate，commit的日誌作為單獨的redo record產生，一共2條redo record，第二個redo record為commit產生的，見紅色部分(OP:5.4,代表為UNDO段頭的修改）
REDO RECORD - Thread:1 RBA: 0x00044d.00000002.0010 LEN: 0x0230 VLD: 0x05
SCN: 0x0000.041b921c SUBSCN:  1 06/25/2013 11:27:32
(LWN RBA: 0x00044d.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.041b921c)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b91d1 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0016 sqn: 0x00002bee flg: 0x0012 siz: 136 fbi: 0
            uba: 0x00d1a78d.0068.2c    pxid:  0x0000.000.00000000
CHANGE #2 TYP:2 CLS:1 AFN:9 DBA:0x024002c5 OBJ:15750 SCN:0x0000.041b916a SEQ:1 OP:11.2 ENC:0 RBL:0
省略

REDO RECORD - Thread:1 RBA: 0x00044d.00000004.0010 LEN: 0x00d0 VLD: 0x05
SCN: 0x0000.041b921e SUBSCN:  1 06/25/2013 11:27:34
(LWN RBA: 0x00044d.00000004.0010 LEN: 0001 NST: 0001 SCN: 0x0000.041b921d)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b921c SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0016 sqn: 0x00002bee srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00d1a78d.0068.2c ext: 104 spc: 2050 fbi: 0

DUMP LOG FILE：啟用私有redo和imu，設定commit_logging為batch，commit作為一個改變向量合併進了事物的redo record裡，作為一條redo record，change #3為commit產生的。
REDO RECORD - Thread:1 RBA: 0x00044d.00000002.0010 LEN: 0x0230 VLD: 0x05
SCN: 0x0000.041b921c SUBSCN:  1 06/25/2013 11:27:32
(LWN RBA: 0x00044d.00000002.0010 LEN: 0002 NST: 0001 SCN: 0x0000.041b921c)
CHANGE #1 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b91d1 SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh redo: slt: 0x0016 sqn: 0x00002bee flg: 0x0012 siz: 136 fbi: 0
            uba: 0x00d1a78d.0068.2c    pxid:  0x0000.000.00000000
CHANGE #2 TYP:2 CLS:1 AFN:9 DBA:0x024002c5 OBJ:15750 SCN:0x0000.041b916a SEQ:1 OP:11.2 ENC:0 RBL:0
CHANGE #3 TYP:0 CLS:51 AFN:3 DBA:0x00c04c80 OBJ:4294967295 SCN:0x0000.041b921c SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm redo: slt: 0x0016 sqn: 0x00002bee srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00d1a78d.0068.2c ext: 104 spc: 2050 fbi: 0

個人感覺commit_logging引數的作用不大，可能有助於減少ACID的異常時間，對日誌量的size在batch模式下有輕微的減少。
PL/SQL commit優化
傳統情況下，當用戶發出commit後，使用者會話會等待log file sync直到lgwr寫完成。LGWR寫完成後，通知處於前臺程序繼續處理後面的操作。這個機制保障了事務的永續性，滿足了事務ACID的D。但是PL/SQL不是這麼工作的：PL/SQL裡的commit 操作不會等待lgwr寫完成就可以繼續處理後面的操作。簡單的看個例子：
begin
for r in (select id from t1 where mod(id, 20) = 0) loop
update t1 set small_no = small_no + .1 where id = r.id;
commit;
end loop;
end;
/
檢視session 和 sys相關的統計資訊如下：

user commits (session statistic)      25
messages sent (session statistic)      6
redo synch writes(session statistic)   1
log file sync (session events)         1
messages received (lgwr statistic)     6
redo writes (lgwr statistic)           6
log file parallel write (lgwr events)  6
Lgwr僅僅寫了6次（log file parallel write），使用者會話僅僅等待了log file sync一次。那意味著會話發出commit命令後，並沒有停下來等待lgwr寫完成，就繼續處理後面的事務了。使用者會話沒有遵守事務的持久化原則！！如果例項在PL/SQL處理的過程中crash，那麼某些提交的事務是不可恢復的。Oracle對此有一個貌似合理的解釋，在PL/SQL沒有處理完畢之前，你不知道已經提交了多少次，Oracle不會使他們可恢復，只有在PL/SQL結束的時候，增加redo sync writes次數和前臺程序進入log file sync等待。在進行PL/SQL處理期間，不停的檢視等待事件，後臺看不到任何的log file sync等待。還有就是統計資料裡顯示了會話總共向lgwr傳送了6次message sent請求（請求寫日誌），lgwr也接受到了6次message recived資訊，並且寫了6次（log file parallel write）。你可能會問，到底多久，會話傳送一次寫請求？每次前臺程序給LGWR傳送寫請求前，會去持有redo writing latch，然後檢查lgwr是不是已經在處理寫請求了，如果lgwr已經在寫了，前臺程序不會向LGWR傳送請求，也不會等待log fil sync，直接繼續完成後續的操作，如果lgwr沒在寫，前臺程序通知lgwr去寫，但是不會等待log file sycn，還是繼續完成後續的操作，只有在PL/SQL結束的時候，才會最終等待一次log file sync。因此如果你的磁碟寫的速率足夠快，那麼lgwr就會被post的次數越多，成正比的關係。還有如果你的cpu足夠強，那麼PL/SQL塊loop的時間就足夠小，時間小了，那麼lgwr被post的次數也就少了，成反比的關係（在磁碟寫速率一定的情況下）。
值得注意的是，如果PL/SQL裡包含了DBLINK，那麼就會使用傳統的提交方式，不會產生出這樣的“異常”。   
最後提醒一句：雖然PL/SQL只有在結束的時候才會等待lgwr寫完成，產生log file sync等待，但是不要認為，在PL/SQL執行過程中，例項crash掉，此次PL/SQL處理的所有事務就會丟失，不是這樣的，只是丟失部分，pl/sql在執行過程中，會話是一直檢查lgwr是不是在工作的，如果沒在工作，就傳送寫請求給lgwr的（message sent），lgwr接收到寫請求後，就要寫日誌，只要是被寫進了日誌檔案的事務就是可恢復的。也就是說，雖然前臺沒有等待log file sync，但是後臺其實一直是在忙著處理你的事務日誌的。

發現問題的手段
方式一：從awr裡去發現，依據avg wait(ms）去判斷系統的log file sync和log file parallel write是否存在問題。

方式二：通過moats工具去診斷當前資料庫的top wait有哪些，是否有log file sync、log file parallel write，工具下載地址：http://www.oracle-developer.net/utilities.php。
方式三：通過lewis的snap_events指令碼，獲得系統級別等待事件的等待次數、平均等待時間。
rem                execute snap_events.start_snap
rem                execute snap_events.end_snap

方式四：通過tanel poder的snap指令碼取樣lgwr後臺程序的等待事件分佈以及lgwr程序相關的統計資訊。

SQL> @snapper out 1 10 1096
-- Session Snapper v2.01 by Tanel Poder ( http://www.tanelpoder.com )
---------------------------------------------------------------------------------
SID, USERNAME , TYPE, STATISTIC , DELTA, HDELTA/SEC, %TIME, GRAPH
---------------------------------------------------------------------------------
1096, (LGWR) , STAT, messages sent , 12 , 12,
1096, (LGWR) , STAT, messages received , 10 , 10,
1096, (LGWR) , STAT, background timeouts , 1 , 1,
1096, (LGWR) , STAT, physical write total IO requests , 40, 40,
1096, (LGWR) , STAT, physical write total multi block request, 38, 38,
1096, (LGWR) , STAT, physical write total bytes, 2884608 , 2.88M,
1096, (LGWR) , STAT, calls to kcmgcs , 20 , 20,
1096, (LGWR) , STAT, redo wastage , 4548 , 4.55k,
1096, (LGWR) , STAT, redo writes , 10 , 10,
1096, (LGWR) , STAT, redo blocks written , 2817 , 2.82k,
1096, (LGWR) , STAT, redo write time , 25 , 25,
1096, (LGWR) , WAIT, LGWR wait on LNS , 1040575 , 1.04s, 104.1%, |@@@@@@@@@@|
1096, (LGWR) , WAIT, log file parallel write , 273837 , 273.84ms, 27.4%,|@@@ |
1096, (LGWR) , WAIT, events in waitclass Other , 1035172 , 1.04s , 103.5%,|@@@@@@@@@@|
-- End of snap 1, end=2010-03-23 12:46:04, seconds=1

相關的等待事件
1）log file sync（前臺程序的等待事件）
2）log file parallel write（後臺程序lgwr的等待事件）
3）log buffer space
lgwr重新整理太慢可能會導致這個問題，導致lgwr重新整理慢也有幾種情況
  1.IO子系統太慢
  2.lgwr不能獲得足夠的cpu資源
  3.遭遇了大事務(expdp,insert /*+ append */ as ,imp,create as )
也可能是log buffer設定的太小了，不過在現在已經不太可能。預設的尺寸已經很大了。
4）log file single write
這個等待產生的原因是對日誌檔案頭塊的讀寫。一般在如下情況下會產生：
1)日誌切換
2)歸檔

log file sync與buffer busy waits
事物在進行提交的時候，對事物修改的，還在記憶體裡的塊做commit cleanout，其實主要就是設定ITL槽位裡的commit scn，不會去清楚lb資訊。ORACLE在進行commit cleanout期間，會獲取相關buffer的buffer pin，而且是排他模式獲取，這個pin直到lgwr把日誌刷入到磁碟才釋放，如果在此期間，有程序對相關的buffer進行select/update/insert就會造成buffer busy waits。因此如果你的系統log file sync指標很高，也可能會導致一定程度的buffer busy waits等待事件。

常用的 log file sync等待時間的優化手段

一、 　log file sync平均等待事件時間超過7ms，如果等待時間過長，說明log write每次寫入的時間過長，如果能夠優化redo日誌檔案儲存，使之存放在更快的磁碟上，就可以減少這個等待事件的單次等待時間。（RAID 5--> RAID 10）
  　當無法通過優化redo日誌的I/O效能來解決問題，或者優化了redo日誌的I/O效能後還是無法達到我們的預期，那麼該如何處理呢？

  二、 有經驗的DBA可能會建議加大日誌緩衝區（log buffer）。提到加大日誌緩衝區，可能有些朋友就會感到疑惑，redo日誌檔案寫等待時間長怎麼會和日誌快取衝區直接關聯起來呢？實際上這個問題解釋起來一點也不難，如果資料檔案的I/O效能有問題，平均單塊讀的等待時間偏長，那麼通過加大db cache來減少I/O總次數，從而達到優化I/O的效果。加大日誌快取區的原理也是一樣的，這樣可以使
    日誌快取中的儲存更多的redo日誌資料，從而減少由於redo日誌快取區不足而產生lgwr寫操作的數量，使平均每次寫入redo日誌檔案
　　的redo位元組數增加，從而減少redo的I/O次數，進而達到優化log file sync等待事件的目的。

　三、如果上述兩種方法都不行時，還有一種方法：就是減少提交的次數。如果提交過於頻繁，那麼無論怎麼優化都無法徹底解決問題。
　通過加大一次提交記錄的數量，減少提交批次，可以有效地減少log file sync等待時間。採用此方法就意味著需要對應進行較大的調整，甚至要對應用架構做出修改，這種修改的代價將十分巨大。
　　
　四、還有一個方案可以優化log file sync事件，就是把部分經常提交的事務設定為非同步提交。
　　非同步提交是10g版本引入的新特性，通過設定commit_write引數，可以控制非同步提交。
　　commit_write引數預設值是“immediate,wait”
    可以設定為“immediate,nowait”來實現非同步提交。
    採用非同步提交的系統需要做一些額外的校驗和處理，清理不一致的資料，重新插入剛才由於非同步提交而丟失的資料。這就需要在應用層面進行一些特殊處理，建校驗機制和錯誤資料處理機制。我們需要在應用層面進行一些特殊的設定。應該注意的是，那些特別重要的，後續無法重新完全補充的資料不適合使用這種方法
　　

  log file sync等待事件是十分關鍵的，我們在資料庫的日常維護中應該對此指標建立基線，如果這個指標有異常變化，一定要儘快分析並解決問題。一旦這個指標惡化，可能導致系統性能急劇下降，甚至會導致短暫的掛起。去年，一個客戶的系統，平時log file sync的指標是2-3ms。在一次巡檢時老白髮現該指標增長到了7ms, 當時巡檢報告中建議客戶關注這個指標，並儘快檢查儲存系統和作業系統，查出變慢的原因。客戶檢查了儲存，沒發現故障，於是就不了了之了。在下個月巡檢的時候，發現該指標增長到了13ms,再次預警，依然沒有發現問題。隨後兩個月這個指標一直持續惡化，增長到了20多毫秒。由於前面幾個月的檢查工作沒有發現問題，而目前系統也還是很正常的，所以客戶也沒有再去認真核查。終於有一天，系統突然掛起，５分鐘後才恢復正常。後來檢查原因，就是log file sync等待導致。根據我的建議，客戶從頭到尾檢查了一遍，最終發現LVM的一條鏈路存存閃斷現象，修復了鏈路後，一切都恢復正常了。
  　　　
　　　通過上面的案例，我們要吸取教訓，如果log file sync指標有所惡化，一定要儘快排查問題的根源，如果log file sync的等待時間持續上升，那麼系統出現掛起的可能性也在增加。儘快找到問題的原因是勢在必行的。