重做日志文件是Oracle數據庫中一種非常重要的日志文件，也是其一個很有特色的功能。重做日志文件會紀錄對於數據庫的任何操作，如利用DML語句或者DDL語句對數據進行更改，或者數據庫管理員對數據庫結構進行更改，都會在重做日志中進行記錄。
可見，當數據被意外的刪除或者修改，我們可以利用重新日志文件進行恢復; 當出現例程失敗或者介質失敗的情況下，也可以利用日志文件實現例程恢復或者介質恢復。所以說，我們若能夠管理好重做日志文件的話，對於保障數據庫數據的安全是非常重要的。
下面筆者談談管理好Oracle 數據庫日志文件的幾點經驗技巧，或許，能夠給大家在重做日志文件的管理中帶來一些啟示。
一、合理確定重做日志文件的存放位置
我們知道，當數據庫內部數據丟失或者被意外更改的情況下，數據庫管理員可以利用重做日志文件實現數據庫數據的恢復工作。當數據庫出現意外事故，如硬盤物理損壞、數據丟失時怎麼辦?
我們第一個就會想到利用數據庫重做日志對數據進行恢復。可是當數據庫重做日志跟數據庫數據文件放在同一個硬盤的話，很明顯，當硬盤損壞的時候，數據文件將跟日志文件共赴黃泉。此時，連天皇老子都救不了我們。
所以，此時，我們就有必要把重做日志文件跟數據庫數據文件放在兩個不同的硬盤上面。此時，任何一個硬盤若發生損壞，我們都可以憑借另外一塊硬盤的數據，來挽回損失。如存放數據文件的硬盤損壞時，我們就可以利用存放在另外一塊硬盤上的數據重做日志文件進行修復，挽回損失。
雞蛋不能放在同一個籃子裡，故重做日志文件與數據文件也不要放在同一塊硬盤上。那時非常危險一個動作。
其實，這個重做日志文件就跟數據庫的備份文件類似。我們在對數據庫進行備份的時候，都知道需要進行異地備份。可惜的是，很多數據庫管理員，在進行Oracle 數據庫管理的時候，沒有注意到這一點，結果當出現問題的時候，就來不及了。故，對於數據重做日志文件，保存時，要跟數據庫備份文件一樣，進行異地保存。
二、合理設置數據庫的歸檔模式
因為數據重做日志會紀錄數據庫所有的修改動作，所以，當數據庫頻繁修改時，如那些ERP系統需要頻繁對數據庫進行修改操作，此時，數據庫的重做日志文件就會很龐大。為了便於日志文件的管理，Oracle 數據庫默認情況下，在安裝的時候，會有三個重做日志文件。當第一個重做日志文件達到一定容量時，就會停止寫入，而會轉向第二個日志文件; 第二個也滿時，就會轉向第三個。當第三個滿時，就會往第一個日志文件中寫入。在往這原來的紀錄中寫入重做日志文件的時候，是否需要對原有的紀錄進行備份呢?根據用戶需求的不同，就存在這兩種處理模式。一種是不需要數據庫進行自動備份，這種模式就叫做非歸檔模式; 而當重做日志改寫原有的重做日志文件以前，數據庫會自動對原有的日志文件進行備份的話，這種操作模式就叫做歸檔模式。
現在擺在數據庫管理員面前有兩個選擇。選擇歸檔模式或者非歸檔模式呢?
這要根據企業對於數據完整性的要求不同而采取不同的操作模式。筆者的建議是，采用歸檔模式。因為現在硬盤非常的便宜，故我們可以花比較少的代價，換取比較齊全的數據庫重做日志文件，個人認為這對於企業來說，是很值得的。、
筆者現在的做法是，重做日志文件至少保存一年。也就是說，當一年過後，就可以重寫原來的日志文件。這主要是跟企業所處的行業以及對於數據的安全性程度不同而有所區別。如銀行就不同，他們可能要求重新日志保留十年甚至更長的時間。要知道，對於他們來說，任何一條記錄可能都涉及到很大的資金。
三、合理選擇日志切換的方法
日志切換是指停止向某個重做日志文件組寫入而向另一個聯機的重做日志文件組寫入的那一剎那，我們稱為日志切換。一般來說，這個日志切換主要有三種處理方式。通常情況下，使到重做日志文件組容量滿的時候，會發生日志切換動作。另外，我們還可以以時間的方式指定日志切換的方式，如我們可以以一個星期或者一個月作為切換的單位。第三，有時候我們可能出於數據庫維護的需要，如當發現存放數據重做日志的硬盤容量快用光時，我們需要換一塊硬盤，此時，就需要在當前時刻，進行日志的切換動作，這我們一般稱之為強行日志切換。
歸檔就是在重做日志文件被覆蓋時，將重做日志文件通過復制操作系統文件的方式，保存到其他指定的位置。一般情況下，只有在處於歸檔日志模式下的數據庫中，才會對重做日志文件進行歸檔動作。
日志切換的模式選擇，一般對於數據的安全性沒有很大關系，但是，對於我們進行數據重做日志的管理，卻會產生很大影響。合理部署重做日志文件的切換方法，對於我們數據庫管理員來說，具有非常的現實意義。我們設置的好，可以大大節省我們數據庫的管理工作，提高數據庫的自動化管理效率。
如筆者現在對於數據重做日志是如此管理的。
根據筆者對於數據庫變動的觀察，筆者在新建立數據庫的時候，設置了六個數據庫重做日志文件。然後筆者采用基於時間的方是進行數據日志的切換動作。每兩個月進行切換一次。為什麼要選擇這個時間呢?一方面是出於這個重做日志文件大小的考慮，另一方面，也是出於日後查詢與管理的需要。如此的話，一年六個數據重做日志文件，就非常的清楚。
但是，基於時間的策略來對重做日志文件進行切換的話，有一個不好的地方，就是對於重做日志文件的大小很難控制。如可能在應用系統前期部署階段，如ERP系統前期數據倒入階段，因為涉及到很多的數據更改動作，所以，這個數據重做日志文件就會非常的大。而到後來項目上線，業務趨於正常的時候，數據重做日志文件大小又會迅速的回落。這就會導致數據重做日志文件大小差異太大，而數據重做日志的多路復用或者歸檔帶來一定的麻煩。筆者的做法是，當ERP系統前期數據更新完畢，項目上線時，先對數據庫進行強制數據重做日志切換。對於這個重做日志進行獨立的管理。如此的話，後續的重做日志容量大小就會差不多，易於我們管理。
四、來自官方的建議
下面兩條是來自Oracle數據庫官方的對於重做日志管理的建議。由於筆者所涉及到的數據庫還沒有復雜到這種程度，所以對於這兩個建議還沒有直觀的印象。各位讀者若覺得有必要的話，也可以參考一下。
一是如果采用了歸檔模式的話，應該將重做日志成員放置到不同的硬盤中去。以消除LGWR和ARCH後台進程對重做日志成員的爭奪。也就是說，如有憂多組多路復用重做日志成員，則可以將每個成員都放置在不同的硬盤上，並且將其歸檔重做日志文件也放在另外的硬盤上。這個筆者還沒有測試過，到底其可以提高多少數據庫的性能。這麼處理的目的，筆者想，大概為了減少填寫成員與讀取成員、歸檔成員之間的沖突。具體效果如何，就待大家去測試了。
二是不應該將數據日志文件存放在非常活躍的數據或索性表空間的硬盤上。這會降低數據庫正常讀取的效率。這個從理論上是可以理解的，但是在實際應用中，會取得多大的成效，因為筆者沒有親身感受過，也就不得而知了。
