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