log buffer及日誌管理深入分析及效能調整（五）

的最佳化

我們一般不太會關注日誌緩衝區的最佳化。這是因為日誌緩衝區的爭用一般不會是的主要效能問題。前面我們已經知道，日誌塊的都是按照順序往裡寫，不存在更新日誌塊的以前的內容，同時每個日誌塊大小都很小，所以幾乎不會有多個程式搶同一個日誌塊的情況。其爭用主要是程式由於找不到可用的日誌塊而必須等待的情況。而我們知道LGWR負責釋放髒的日誌塊從而提供可用日誌塊，LGWR在日誌緩衝區中的髒日誌塊超過1M或者超過日誌緩衝區的1/3時就會啟動，而且在將重做記錄寫入聯機日誌檔案時，都是按照順序寫入，不存在類似DBWR的隨機寫入，所以寫入的速度是非常快的，除非硬碟的I/O速度有很大的問題。可以執行下面的語句來判斷硬碟的I/O是否過慢。

SQL > select total_waits,time_waited,average_wait,time_waited/total_waits as avg

 2 from v$system_event where event = 'log file parallel write';

TOTAL_WAITS TIME_WAITED AVERAGE_WAIT       AVG

----------- ----------- ------------ ----------

 314346633  129581305           0 .41222425

我們可以看到，AVERAGE_WAIT表示LGWR完成一次寫入平均需要多少時間，是用等待時間除以等待次數得出的、並四捨五入以後得到的平均值（AVG是沒有四捨五入以後的值）。如果AVERAGE_WAIT大於1，就表示硬碟的I/O比較慢。

不過，對於整個資料庫的健康檢查來說，還是需要衡量一下資料庫的日誌緩衝區是否存在健康隱患。所以也還是需要了解一些有關日誌緩衝區效能的一些指標。

的統計資訊

有關log buffer的統計資訊，我們都可以從v$sysstat裡找到。我們可以執行一個DML語句，然後比較前後的統計資訊，看看都發生了哪些變化。

SQL> select name,value from v$sysstat where name like '%redo%' order by name;

NAME                                                                 VALUE

---------------------------------------------------------------- ----------

redo blocks read for recovery                                          110

redo blocks written                                                  13617

redo buffer allocation retries                                           0

redo entries                                                         16868

redo log space requests                                                  0

redo log space wait time                                                 0

redo log switch interrupts                                               0

redo ordering marks                                                      1

redo size                                                          6228264

redo subscn max counts                                                   0

redo synch time                                                        207

redo synch writes                                                     2475

redo wastage                                                        519976

redo write time                                                       1105

redo writer latching time                                                0

redo writes                                                           1991

 

SQL> update redo_test set name='cdf' where id=1;

SQL> commit;

SQL> select name,value from v$sysstat where name like '%redo%' order by name;

NAME                                                                 VALUE

---------------------------------------------------------------- ----------

redo blocks read for recovery                                          110

redo blocks written                                                  13619

redo buffer allocation retries                                           0

redo entries                                                         16869

redo log space requests                                                  0

redo log space wait time                                                 0

redo log switch interrupts                                               0

redo ordering marks                                                      1

redo size                                                          6228856

redo subscn max counts                                                   0

redo synch time                                                        207

redo synch writes                                                     2476

redo wastage                                                        520376

redo write time                                                       1105

redo writer latching time                                                0

redo writes                                                           1992

             我們可以看到有些統計資訊發生了變化，而有些則沒有。這些統計資訊都是累計值，自從例項啟動以

來就一直累加而產生的。我們依次解釋一些重要的統計資訊。

<!--[if !supportLists]--&gt1)     <!--[endif]--&gtredo writes、redo blocks written、redo write time：這三個統計資訊是主要的統計資訊，在LGWR寫完重做記錄以後更新，而且只能由LGWR負責更新。redo writes表示寫了多少次，我們可以看到上例中寫了1次（1992-1991）；redo blocks written表示總共寫了多少日誌塊，可以看到寫了2個日誌塊（13619-13617），由此我們可以知道平均寫一次可以寫2個日誌塊。redo write time表示將重做記錄寫入日誌檔案花了多少時間，單位是10個毫秒，我們可以看到為了寫這2個日誌塊所需要的時間都幾乎為0（1105-1105）。

<!--[if !supportLists]--&gt2)     <!--[endif]--&gtredo size、redo entries：這兩個統計資訊是在重做記錄複製到日誌緩衝區之前更新的。它們都表示產生了多少量的重做記錄，redo size以位元組為單位，而redo entries以個數為單位。比如，上例中產生了592（6228856-6228264）個位元組的重做記錄，共1（16869-16868）個重做記錄，平均每個重做記錄為592個位元組。

<!--[if !supportLists]--&gt3)     <!--[endif]--&gtredo wastage：該記錄表示當日志緩衝區的日誌塊被寫入日誌檔案時，日誌塊中沒有被利用的空間數量，以位元組為單位。因為當把重做記錄複製到日誌緩衝區中的日誌塊時，需要格式化日誌塊以後才能實際存放日誌資訊，這樣就會“浪費”一些日誌緩衝區空間。上例中，我們可以看到為了格式化日誌塊而浪費了大約400（520376-519976）個位元組的空間。

<!--[if !supportLists]--&gt4)     <!--[endif]--&gtredo log space requests、redo log space wait time：redo log space requests表示對聯機日誌檔案空間請求的次數，redo log space wait time表示在發出請求空間以後的等待時間。這兩個統計資訊只有在前臺程式請求聯機日誌檔案空間未果的情況下才會增加，這時前臺程式等待日誌切換完成。在沒有人為的發出alter system switch logfile命令的前提下，redo log space requests就表示日誌切換的總次數。

<!--[if !supportLists]--&gt5)     <!--[endif]--&gtredo buffer allocation retries：表示再次嘗試在日誌緩衝區中分配可用空間的次數。當程式第一次沒能在日誌緩衝區中獲得可用空間時，該程式必須等待LGWR重新整理日誌緩衝區或者等待日誌切換完成等，然後會再次嘗試獲取空間。理想情況下，該統計資訊應該為0。

<!--[if !supportLists]--&gt6)     <!--[endif]--&gtredo synch writes，redo synch time：這兩個統計資訊是在使用者每次提交（commit）時增加。redo synch writes表示由於提交而重新整理日誌緩衝區的次數，而redo synch time表示由於提交而重新整理日誌緩衝區所花的時間，以10個微妙為單位。