LOG FILE SYNC概述（第五篇）

其他組建的調優

log file sync問題的解決是一個系統工程，除了上面一節描述的調優方式，我們看看對於其他組建是否也需要調優。例如commit本身作為一個redo record也是需要被複製進log buffer的，如果此時log buffer太小沒有了空間，那麼豈不是也會在一定程度上影響提交的效率，再如，Lgwr在重新整理日誌前，需要確認所有分配過空間的buffer都已經複製結束，如果發現還有程式在持有redo copy latch就說明還有程式正在往log buffer複製日誌，那麼這個時候也會導致提交變慢。

LOG BUFFER 的調優

10G以後，LOG BUFFER一般情況下已經比較大，一般為1到多個granules大小，除非你看到了比較多的log buffer space等待事件，否則不需要調整log buffer的大小。

redo相關latch的調優
l redo copy latch：僅僅用來跟蹤是否有程式正在往log buffer裡複製資料。lgwr在真正開始寫之前，必須等待相關的程式複製完畢，在此期間,lgwr會等待LGWR wait for redo copy等待。可以同時向log buffer裡進行複製的程式的數量由_log_simultaneous_copies決定。除非觀察到明顯的redo copy latch等待，否則保持預設值。

l redo allocation latch：保護程式在redo buffer裡分配空間時使用，保證各個程式間彼此分配的空間不重疊。9.2版本以前由於redo allocation latch只有一把，因此比較容易引起此latch的真用，9.2版本以後，根據主機CPU的多少，log buffer已經被拆分成多個子LOG BUFFER，每個子buffer 都有有對應的redo allocation latch，很大程度上緩解了redo allocatoin latch的爭用，除非看到了明顯的redo allocation latch的爭用，否則不用調整log buffer的數量。10G以後，私有redo和IMU的出現，每一個私有redo都由一個私有的redo allocation latch保護，進一步降低了redo allocation latch的爭用。

 redo writing latch：這個latch保護的是一個標誌位，程式獲取這個latch後，修改標誌位，比如把0改為1，代表lgwr正在寫，這樣後續的提交程式，獲得這個latch後讀取標誌位，就知道當前LGWR是不是正在寫了，避免了很多不需要的重複通知。

一般是不需要的，除非他們相關的等待已經引起了你的注意，而且ORACLE各個版本也一直在最佳化相關的latch的獲取和釋放，比如redo allocation latch，這一塊已經做的非常高效了。

新的調優手段

10G之前，在事務做提交的時候，必須等待Lgwr刷日誌完成才能繼續做其它事，也就是說必須符合事務持久化的條件，可能學過其他資料庫的同學學ORACLE的時候怪怪的，因為像MYSQL、MONGODB等資料庫都支援對日誌的非同步重新整理，我想之所以ORACLE這麼晚才推出這一功能，主要還是使用ORACLE的客戶都是金融、證券等行業巨多，這些行業對於資料的丟失是零容忍的，因此他們對此並無需求，直到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的改變向量（修改回滾段頭的事務槽）將作為stand alone（單獨的）的redo record產生，跟9I的commit記錄日誌的方式是一樣的。batch 模式下commit改變向量的記錄方式是合併進事務產生的change vector裡，作為一個redo record,這個batch模式依賴是否使用私有redo和IMU，如果私有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模式下有輕微的減少。