[轉載]oracle日誌操做模式(歸檔模式和非歸檔模式的利與弊)

筆者今天就談談本身對這兩種操做模式的理解，而且給出一些可行的建議，跟你們一塊兒來提升Oracle數據庫的安全性。 

1、非歸檔模式的利與弊。 

　　非歸檔模式是指不保留重作歷史的日誌操做模式，只可以用於保護例程失敗，而不可以保護介質損壞。若是數據庫採用的是日誌操做模式的話，則進行日誌切換時，新的日誌會直接覆蓋原有日誌文件的內容，不會保留原有日誌文件中的數據。 
　　這麼說聽起來可能比較難理解。筆者舉一個簡單的例子，就會清楚許多。如如今Oracle數據庫中有四個日誌組，日誌序列號分別爲十一、 十二、1三、14。當數據庫事務變化寫滿第一個日誌組文件(序列號爲11)時，Oracle數據庫就會自動切換到第二個日誌組文件(序列號爲12)中。依次類推。當第三個日誌組文件(序列號爲13)寫滿時，就會切換到第四個日誌組(序列號爲14)。當第四個日誌組(序列號爲14)滿時，其就會切換到第一個日誌組(序列號爲15)。這裏，序列號雖然與剛纔第一個日誌文件組不一樣，可是日誌組仍然是同一個。此時，因爲數據庫的操做模式選擇爲非歸檔模式，因此第一組日誌文件(序列號爲11)中的內容並無歸檔。新的日誌文件的內容將直接覆蓋第一個日誌組文件中的內容。若第一個日誌組文件(序列號爲15)滿時，切換到第二個日誌文件組時，新的內容又會在第二個日誌文件組沒有歸檔的狀況下，直接覆蓋日誌文件12中的原有數據。 

　　經過以上的分析，咱們能夠概括出非歸檔操做日誌模式的一些特色。 

　　一是當檢查點完成以後，後臺進程能夠覆蓋原有重作日誌的內容。也就是說，在日誌切換時，後來的日誌文件內容能夠在之前的日誌文件內容沒有歸檔的狀況下，覆蓋原有日誌文件的內容。如此的話，當出現數據文件損壞時，數據庫管理員只可以恢復到過去的徹底被分點。如數據庫有四個日誌組。若是在日誌組序列號爲16的時候數據庫管理員進行了徹底備份。而在日誌組序列號爲28的時候數據文件出現了損壞。此時，因爲中間的日誌文件內容被覆蓋掉了。因此，此時數據庫管理員只可以恢復到徹底備份的那個點，而不可以恢復數據庫文件損壞時的點的數據(即序列號爲28)的數據。若是在序列號爲18的時候出現了數據文件損壞的事故，則能夠先對數據庫進行還原(還原點爲序列號爲16時的數據)，而後再利用重作日誌文件(序列號爲1七、18)，便可以把數據恢復到故障發生時的數據。故雖然不用對重作日誌文件進行歸檔，節省磁盤空間。可是，卻給後續數據庫的恢復帶來的麻煩，下降了數據庫的安全性。爲此，如何取捨，仍是須要數據庫管理員根據本身企業的狀況，做出選擇。 

　　二是執行數據庫備份時，必需要備份全部數據文件和控制文件。根據上面筆者所講述的，由於重作日誌會被後來的所覆蓋，因此，基本上數據庫管理員不可以經過重作日誌文件來恢復數據庫的數據，或者說，經過重作日誌文件不可以恢復所有的數據。爲此，在執行數據庫備份時，就必須備份全部的數據文件和控制文件。同時，還必須使用SHUTDOWNNORMAL等命令關閉數據庫。 
　　 
2、歸檔日誌模式。 

　　歸檔日誌模式與非歸檔日誌模式相對應，是指保留重作日誌歷史的日誌操做模式。這種日誌操做模式不只可用於保護例程失敗，還能夠用於保護介質損壞的狀況。若是數據庫管理員把日誌設置爲歸檔日誌模式，則當後臺進程在進行日誌切換時，後臺進程會自動將重作日誌的內容複製到歸檔日誌中。歸檔日誌就是非活動重作日誌的備份。 

　　如如今Oracle數據庫中有四個日誌組，日誌序列號分別爲十一、十二、1三、14。當數據庫事務變化寫滿第一個日誌組文件(序列號爲11) 時，後臺進程就會切換到第二個日誌組中(序列號爲12)。不過在這個切換以前，數據庫有一個進程，會負責將第一個日誌組中的文件內容複製到歸檔日誌中去。依次類推。這就是歸檔日誌模式與非歸檔日誌模式最本質的區別。不過這個區別卻給數據庫安全性帶來了很大的變化。 

　　如當日志序列號爲28時出現了數據文件的錯誤或者服務器硬盤損壞的事故時，由於日誌文件中記錄了從數據庫備份以來全部的數據變化狀況。並且這些日誌文件與數據庫備份文件存儲在其餘媒體中，那麼數據庫管理員就能夠經過這些資料，把數據庫恢復到介質損壞時(即日誌文件序列號爲28)的數據。從保護數據庫數據的角度講，這是一個接近於比較理想的狀態了。 

　　若把非歸檔模式與歸檔模式進行對比的話，能夠發現歸檔模式有以下的特色。 
一是當出現介質損壞(如硬盤損壞或者意外刪除數據文件)或者出現例程失敗(如服務器忽然斷電)時，數據庫管理員能夠憑藉歸檔日誌文件來防止丟失數據。而非歸檔模式則每每只可以應對例程失敗的狀況。因此，其應用範圍要比非歸檔模式大的多。 

　　二是數據備份的限制條件。正如上面所說的，若是數據庫處於非歸檔模式，則對數據庫進行備份時，要先用SHUTDOWNNORMAL等命令關閉數據庫。而處於歸檔模式的時候，則當數據庫處於Open狀態時，數據庫管理員仍然能夠備份數據庫，並且不會影響數據庫的正常使用。除了數據庫備份二者有本質上的差別以外，在數據庫恢復上也有很大的差異。若數據庫採用歸檔日誌模式，不只能夠執行徹底恢復，並且在歸檔日誌文件的幫助下，還能夠將數據庫恢復到特定的點。從而當數據庫出現意外故障時，最大限度的保護數據的安全性。 
　　不過若採起歸檔模式的話，則必需要犧牲必定的磁盤空間。 

3、如何選擇合適的日誌操做模式？ 

　　非歸檔模式只適用於例程失敗時恢復數據，不可以用來保護介質損壞。即當數據庫的數據文件意外損壞時，非歸檔模式沒有應對之策。歸檔模式不只能夠用來保護例程失敗，並且還能夠在介質失敗的時候，最大程度的恢復數據庫的原有數據。此時，數據庫管理員能夠利用數據庫備份文件、歸檔日誌文件、重作日誌文件等把數據庫中的數據恢復到故障發生的那一時點。 

　　既然歸檔操做模式與非歸檔操做模式各有各的特色，那麼在何時採用歸檔日誌模式爲好，何時又該採用非歸檔模式呢?這個問題的答案，是公說公有理，婆說婆有理。恐怕爭論個幾年也沒有一個固定的答案。對此，筆者就提一下本身的意見。這也不是標準答案，只是供你們參考。 

　　首先要看數據庫中數據變化的頻繁程度。當數據庫中數據變化比較少的時候，則最好採用非歸檔模式。相反，若是數據庫中的數據變化比較頻繁，如一些業務操做系統，則最好可以採用歸檔模式。 

　　其次，要看企業對數據丟失的態度。若是企業對於數據安全要求比較高，如銀行，不容許丟失任何數據，則最好可以採用歸檔日誌模式。在數據庫意外故障的時候，其能夠幫助數據庫管理員在最大程度上恢復數據。同理，當企業能夠容許部分損壞數據的時候，則能夠採用非歸檔模式，以節省切換日誌組時的對日誌文件備份的額外開銷與磁盤空間。 

　　再者，要看看數據庫是否須要全天候運行。由於在非歸檔模式下，必須利用SHUTDOWNNORMAL等命令關閉數據庫，才能過對數據庫進行備份。這跟數據庫全天候運行的要求是不符合的。而歸檔模式下，即便數據庫出於OPEN狀態，也能夠對其進行備份，也不會影響數據庫的正常運行。爲此，若果數據庫須要全天候運行的話，則最好採用歸檔模式。雖然數據庫爲此要付出一些額外的開銷，筆者認爲也是值得的。畢竟硬件投資有價，數據無價。 

　　數據庫管理員要根據企業的實際狀況，選擇合適的日誌操做模式。從而讓重作日誌與歸檔日誌真正成爲Oracle數據庫的保護傘。

 

轉自：http://www.jb51.net/article/33221.htm