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等待。
我們要是能知道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真正開始寫之前，非?？赡艽嬖谥鴷r間差，就在這個時間差里，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的比重。
如你所見，由于CPU資源的不足、系統負載過大，導致操作系統調度出現了較大的延遲，3,4階段的IO部分的延遲已經不是整個log file sync時間的最大的罪魁禍首！
/*********************************************小插曲*****************************************************************************/
lgwr會post哪些前臺進程？
當lgwr刷新完日志后，會post相應的前臺進程(wakeup）繼續工作，那么lgwr怎么判斷應該wakeup哪些前臺進程呢？
log file sync等待的p1參數的含義為：P1 = buffer# in log buffer that needs to be flushed
當lgwr刷新完buffer后，會掃描活躍會話列表，查看哪些會話在等待log file sync，而且會話的buffer#小于等于它所刷新的log buffer的最大值，這些會話會被wakeup。
/*********************************************小插曲****************************************************************************/
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 。見http://space.itpub.net/22034023/viewspace-751590。
/*****************************************************************************可憐的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等待?？梢酝瑫r向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，這一塊已經做的非常高效了。關于redo allocation latch發展史，查看我的另一篇文章：http://www.itpub.net/thread-1803010-1-1.html
新的調優手段
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模式下有輕微的減少。ACID異常見我的另一個文章：http://www.itpub.net/thread-1803010-1-1.html
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進程相關的統計信息。
來自白大師（白鱔）對log file sync等待事件優化的總結，供各位puber們學習參考：
一、 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, 當時巡檢報告中建議客戶關注這個指標，并盡快檢查存儲系統和操作系統，查出變慢的原因?？蛻魴z查了存儲，沒發現故障，于是就不了了之了。在下個月巡檢的時 候，發現該指標增長到了13ms,再次預警，依然沒有發現問題。隨后兩個月這個指標一直持續惡化，增長到了20多毫秒。由于前面幾個月的檢查工作沒有發現 問題，而目前系統也還是很正常的，所以客戶也沒有再去認真核查。終于有一天，系統突然掛起，５分鐘后才恢復正常。后來檢查原因，就是log file sync等待導致。根據我的建議，客戶從頭到尾檢查了一遍，最終發現LVM的一條鏈路存存閃斷現象，修復了鏈路后，一切都恢復正常了。
通過上面的案例，我們要吸取教訓，如果log file sync指標有所惡化，一定要盡快排查問題的根源，如果log file sync的等待時間持續上升，那么系統出現掛起的可能性也在增加。盡快找到問題的原因是勢在必行的。
-----------------------------------------------------------------------------
來自蓋大師（eygle）對log file sync等待事件優化的總結，供各位puber們學習參考：
http://www.eygle.com/statspack/statspack14-LogFileSync.htm
當一個用戶提交(commits)或者回滾(rollback),session的redo信息需要寫出到redo logfile中.
用戶進程將通知LGWR執行寫出操作,LGWR完成任務以后會通知用戶進程.
這個等待事件就是指用戶進程等待LGWR的寫完成通知.
對于回滾操作，該事件記錄從用戶發出rollback命令到回滾完成的時間.
如果該等待過多，可能說明LGWR的寫出效率低下，或者系統提交過于頻繁.
針對該問題，可以關注:
log file parallel write等待事件
user commits,user rollback等統計信息可以用于觀察提交或回滾次數
解決方案:
1.提高LGWR性能
盡量使用快速磁盤，不要把redo log file存放在raid 5的磁盤上
2.使用批量提交
3.適當使用NOLOGGING/UNRECOVERABLE等選項
可以通過如下公式計算平均redo寫大?。?br />
avg.redo write size = (Redo block written/redo writes)*512 bytes
如果系統產生redo很多，而每次寫的較少，一般說明LGWR被過于頻繁的激活了.
可能導致過多的redo相關latch的競爭,而且Oracle可能無法有效的使用piggyback的功能.
我們從一個statspack中提取一些數據來研究一下這個問題.
我們看到，這里log file sync和db file parallel write等待同時出現了.
顯然log file sync在等待db file parallel write的完成.
這里磁盤IO肯定存在了瓶頸，實際用戶的redo和數據文件同時存放在Raid的磁盤上，存在性能問題.
需要調整.
由于過渡頻繁的提交，LGWR過度頻繁的激活，我們看到這里出現了redo writing的latch競爭.
關于redo writing競爭你可以在steve的站點找到詳細的介紹:
http://www.ixora.com.au/notes/lgwr_latching.htm
Oracle Internals Notes
LGWR Latching
When LGWR wakes up, it first takes the redo writing latch to update the SGA variable that shows whether it is active. This prevents other Oracle processes from posting LGWR needlessly. LGWR then takes the redo allocation latch to determine how much redo might be available to write (subject to the release of the redo copy latches). If none, it takes the redo writing latch again to recordthat it is no longer active, before starting another rdbms ipc message wait.
If there is redo to write, LGWR then inspects the latch recovery areas for the redo copy latches (without taking the latches) to determine whether there are any incomplete copies into the log buffer. For incomplete copies above the sync RBA, LGWR just defers the writing of that block and subsequent log buffer blocks. For incomplete copies below the sync RBA, LGWR sleeps on a LGWR wait for redo copy wait event, and is posted when the required copy latches have been released. The time taken by LGWR to take the redo writing and redo allocation latches and to wait for the redo copy latches is accumulated in the redo writer latching time statistic.
(Prior to release 8i, foreground processes held the redo copy latches more briefly because they did not retain them for the application of the change vectors. Therefore, LGWR would instead attempt to assure itself that there were no ongoing copies into the log buffer by taking all the redo copy latches.)
After each redo write has completed, LGWR takes the redo allocation latch again in order to update the SGA variable containing the base disk block for the log buffer. This effectively frees the log buffer blocks that have just been written, so that they may be reused.
------------------------------------------------------------------------------------
來自呂大師（vage）對log file sync等待事件優化的總結，供各位puber們學習參考：
1、Log File Sync是從提交開始到提交結束的時間。Log File Parallel Write是LGWR開始寫Redo File到Redo File結束的時間。明確了這一點，可以知道，Log file sync 包含了log file parallel write。所以，log file sync等待時間一出，必先看log file parallel write。如果log file sync平均等待時間（也可稱為提交響應時間）為20ms，log file parallel write為19ms，那么問題就很明顯了，Redo file I/O緩慢，拖慢了提交的過程。
2、 Log File Sync的時間不止log file parallel write。服務器進程開始提交，到通知LGWR寫Redo，LGWR寫完Redo通知進程提交完畢，來回通知也是要消耗CPU的。除去來回通知 外，Commit還有增加SCN等等操作，如果log file sync和log file parallel write差距很大，證明I/O沒有問題，但有可能是CPU資源緊張，導致進程和LGWR來回通知或其他的需要CPU的操作，得不到足夠的CPU，因而產 生延遲。
這 種情況下要看一下CPU的占用率、Load，如果Load很高、CPU使用率也很高，哪就是由于CPU導致Log file sync響應時間加長。這種情況下，數據庫通常會有一些并發癥，比如Latch/Mutex的競爭會比平常嚴重些，因為CPU緊張嗎，Latch /Mutex競爭一些會加巨的。
3、 log file sync和log file parallel write相差很大，但CPU使用率也不高，這種情況比較少見，這就屬于疑難雜癥范疇了。I/O也很快，CPU也充足，log fie parallel write響應時間很短，但log file sync響應時間確很大。這是最難定位的情況，可以全面對比下Redo相關資料(v$sysstat中的資料）、Redo相關Latch的變化情況。
比 如，redo synch time的平均響應時間，不是每次redo synch time都有提交，但每次提交必有redo synch time。如果redo synch time向應快，而log file sync慢，則說明Lgwr和進程的互相通知階段出了問題。還有redo entries，這個Redo條目數，真正含意是進程向Log Buffer中寫Redo的次數。redo log space wait time、redo log space requests資料和Log Buffer Space等待事件也要關注下。Log Buffer的大小通常不會影響Log File Sync，但通過Log Buffer的變化，可以了解Redo量的變化。
關于Log Buffer對Log File Sync的影響，
在新IMU機制下，Redo數據先在共享池中，提交時傳到Log Buffer中，如果這時有等待，等待時間是Log Buffer Space。從Log Buffer到磁盤，等待事件才是log file sync。
老機制下也一樣，Log Buffer之前的等待是log buffer space，log buffer之后的等待才是log file sync。
4、控制文件I/O有可能影響log file sync。
此問題還沒來得及深入研究，只是以前在阿里的數據庫中觀察到這一現象。
5、Log File Sycn和Buffer Busy Waits。
沒 有直接關系。是其他原因，比如Redo相關的Latch，導致了Log File Sync和Buffer Busy Waits同時出現。此時Log File Sync和Buffer Busy Waits都不是原兇，真正的原兇是Log Buffer訪問性能下降。
6、以同步模式向遠端DataGuard傳送Redo，也會導致Log File Sync。
Redo是Oracle重要的優化對象，DBWR的工作原理我已經破譯的差不多了，下一目標就是LGWR，可惜還沒來得及搞，以后有時間再為大家詳細總結。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
