oracle日志操作模式(歸檔模式和非歸檔模式的利與弊)
2024-08-29 13:55:35
供稿：網友
筆者今天就談談自己對這兩種操作模式的理解，并且給出一些可行的建議，跟大家一起來提高Oracle數據庫的安全性。
一、非歸檔模式的利與弊。
非歸檔模式是指不保留重做歷史的日志操作模式，只能夠用于保護例程失敗，而不能夠保護介質損壞。如果數據庫采用的是日志操作模式的話，則進行日志切換時，新的日志會直接覆蓋原有日志文件的內容，不會保留原有日志文件中的數據。
這么說聽起來可能比較難理解。筆者舉一個簡單的例子，就會清楚許多。如現在Oracle數據庫中有四個日志組，日志序列號分別為11、 12、13、14。當數據庫事務變化寫滿第一個日志組文件(序列號為11)時，Oracle數據庫就會自動切換到第二個日志組文件(序列號為12)中。依次類推。當第三個日志組文件(序列號為13)寫滿時，就會切換到第四個日志組(序列號為14)。當第四個日志組(序列號為14)滿時，其就會切換到第一個日志組(序列號為15)。這里，序列號雖然與剛才第一個日志文件組不同，但是日志組仍然是同一個。此時，由于數據庫的操作模式選擇為非歸檔模式，所以第一組日志文件(序列號為11)中的內容并沒有歸檔。新的日志文件的內容將直接覆蓋第一個日志組文件中的內容。若第一個日志組文件(序列號為15)滿時，切換到第二個日志文件組時，新的內容又會在第二個日志文件組沒有歸檔的情況下，直接覆蓋日志文件12中的原有數據。
通過以上的分析，我們可以歸納出非歸檔操作日志模式的一些特點。
一是當檢查點完成之后，后臺進程可以覆蓋原有重做日志的內容。也就是說，在日志切換時，后來的日志文件內容可以在以前的日志文件內容沒有歸檔的情況下，覆蓋原有日志文件的內容。如此的話，當出現數據文件損壞時，數據庫管理員只能夠恢復到過去的完全被分點。如數據庫有四個日志組。如果在日志組序列號為16的時候數據庫管理員進行了完全備份。而在日志組序列號為28的時候數據文件出現了損壞。此時，由于中間的日志文件內容被覆蓋掉了。所以，此時數據庫管理員只能夠恢復到完全備份的那個點，而不能夠恢復數據庫文件損壞時的點的數據(即序列號為28)的數據。如果在序列號為18的時候出現了數據文件損壞的事故，則可以先對數據庫進行還原(還原點為序列號為16時的數據)，然后再利用重做日志文件(序列號為17、18)，即可以把數據恢復到故障發生時的數據。故雖然不用對重做日志文件進行歸檔，節省磁盤空間。但是，卻給后續數據庫的恢復帶來的麻煩，降低了數據庫的安全性。為此，如何取舍，還是需要數據庫管理員根據自己企業的情況，作出選擇。
二是執行數據庫備份時，必須要備份所有數據文件和控制文件。根據上面筆者所講述的，因為重做日志會被后來的所覆蓋，所以，基本上數據庫管理員不能夠通過重做日志文件來恢復數據庫的數據，或者說，通過重做日志文件不能夠恢復全部的數據。為此，在執行數據庫備份時，就必須備份所有的數據文件和控制文件。同時，還必須使用SHUTDOWNNORMAL等命令關閉數據庫。
二、歸檔日志模式。
歸檔日志模式與非歸檔日志模式相對應，是指保留重做日志歷史的日志操作模式。這種日志操作模式不僅可用于保護例程失敗，還可以用于保護介質損壞的情況。如果數據庫管理員把日志設置為歸檔日志模式，則當后臺進程在進行日志切換時，后臺進程會自動將重做日志的內容復制到歸檔日志中。歸檔日志就是非活動重做日志的備份。
如現在Oracle數據庫中有四個日志組，日志序列號分別為11、12、13、14。當數據庫事務變化寫滿第一個日志組文件(序列號為11) 時，后臺進程就會切換到第二個日志組中(序列號為12)。不過在這個切換之前，數據庫有一個進程，會負責將第一個日志組中的文件內容復制到歸檔日志中去。依次類推。這就是歸檔日志模式與非歸檔日志模式最本質的區別。不過這個區別卻給數據庫安全性帶來了很大的變化。
如當日志序列號為28時出現了數據文件的錯誤或者服務器硬盤損壞的事故時，因為日志文件中記錄了從數據庫備份以來所有的數據變化情況。而且這些日志文件與數據庫備份文件存儲在其他媒體中，那么數據庫管理員就可以通過這些資料，把數據庫恢復到介質損壞時(即日志文件序列號為28)的數據。從保護數據庫數據的角度講，這是一個接近于比較理想的狀態了。
若把非歸檔模式與歸檔模式進行對比的話，可以發現歸檔模式有如下的特點。
一是當出現介質損壞(如硬盤損壞或者意外刪除數據文件)或者出現例程失敗(如服務器突然斷電)時，數據庫管理員可以憑借歸檔日志文件來防止丟失數據。而非歸檔模式則往往只能夠應對例程失敗的情況。所以，其應用范圍要比非歸檔模式大的多。
二是數據備份的限制條件。正如上面所說的，如果數據庫處于非歸檔模式，則對數據庫進行備份時，要先用SHUTDOWNNORMAL等命令關閉數據庫。而處于歸檔模式的時候，則當數據庫處于Open狀態時，數據庫管理員仍然可以備份數據庫，而且不會影響數據庫的正常使用。除了數據庫備份兩者有本質上的差異之外，在數據庫恢復上也有很大的差別。若數據庫采用歸檔日志模式，不僅可以執行完全恢復，而且在歸檔日志文件的幫助下，還可以將數據庫恢復到特定的點。從而當數據庫出現意外故障時，最大限度的保護數據的安全性。
不過若采取歸檔模式的話，則必須要犧牲一定的磁盤空間。
三、如何選擇合適的日志操作模式？
非歸檔模式只適用于例程失敗時恢復數據，不能夠用來保護介質損壞。即當數據庫的數據文件意外損壞時，非歸檔模式沒有應對之策。歸檔模式不僅可以用來保護例程失敗，而且還可以在介質失敗的時候，最大程度的恢復數據庫的原有數據。此時，數據庫管理員可以利用數據庫備份文件、歸檔日志文件、重做日志文件等把數據庫中的數據恢復到故障發生的那一時點。
既然歸檔操作模式與非歸檔操作模式各有各的特點，那么在什么時候采用歸檔日志模式為好，什么時候又該采用非歸檔模式呢?這個問題的答案，是公說公有理，婆說婆有理。恐怕爭論個幾年也沒有一個固定的答案。對此，筆者就提一下自己的意見。這也不是標準答案，只是供大家參考。
首先要看數據庫中數據變化的頻繁程度。當數據庫中數據變化比較少的時候，則最好采用非歸檔模式。相反，如果數據庫中的數據變化比較頻繁，如一些業務操作系統，則最好能夠采用歸檔模式。
其次，要看企業對數據丟失的態度。如果企業對于數據安全要求比較高，如銀行，不允許丟失任何數據，則最好能夠采用歸檔日志模式。在數據庫意外故障的時候，其可以幫助數據庫管理員在最大程度上恢復數據。同理，當企業可以允許部分損壞數據的時候，則可以采用非歸檔模式，以節省切換日志組時的對日志文件備份的額外開銷與磁盤空間。
再者，要看看數據庫是否需要全天候運行。因為在非歸檔模式下，必須利用SHUTDOWNNORMAL等命令關閉數據庫，才能過對數據庫進行備份。這跟數據庫全天候運行的要求是不符合的。而歸檔模式下，即使數據庫出于OPEN狀態，也可以對其進行備份，也不會影響數據庫的正常運行。為此，若果數據庫需要全天候運行的話，則最好采用歸檔模式。雖然數據庫為此要付出一些額外的開銷，筆者認為也是值得的。畢竟硬件投資有價，數據無價。
數據庫管理員要根據企業的實際情況，選擇合適的日志操作模式。從而讓重做日志與歸檔日志真正成為Oracle數據庫的保護傘。
