刪除重做日誌檔案組的四大限制條件

雖然重做日誌檔案非常的重要，但是有時候資料庫管理員仍然需要忍痛割愛，將某些重做日誌檔案組或者組成員刪除。如當硬碟出現物理損壞，此時就無法往這個位置存放重做日誌。此時為了避免重做日誌的錯誤，就需要將其刪除，然後再新建一個重組日誌組成員等等。所以，有時是刪除只是為了其更需更好的工作而已。但是刪除重做日誌檔案組或者其成員畢竟不是一件簡單的工作。在做這個操作的時候，資料庫管理員需要注意幾個限制條件。

　　限制條件一：數量上的限制。

　　通常情況下，Oracle資料庫系統治少需要兩個重做日誌檔案組。如果資料庫系統中只有兩個重做日誌檔案組，而出於某種原因資料庫管理員需要刪除其中的一個重做日誌檔案組，則資料庫會拒絕這個操作。如故確實有必要需要刪除這個重做日誌檔案組，那麼資料庫管理員必須先新建一個重組日誌檔案組。然後再把需要刪除的日誌檔案組刪除。這是Oralce資料庫對於重做日誌檔案組數量上的限制，作為資料庫管理員必須無條件的遵守。

　　另外對於組成員來說，也有類似的限制。每個重做日誌檔案組，必須要有一個有效的成員。如因為硬碟介質錯誤等原因需要把唯一的一個組成員刪除，此時Oracle資料庫系統會提示錯誤資訊，拒絕類似的操作。此時資料庫系統如果仍然像保留這個重做日誌檔案組，則只好先建立一個組成員，或者將某個失效的組成員設定為有效，然後再刪除不起作用的組成員。其次需要說明的是，如果在重做日誌檔案中採用多路複用組的話，則最好還要保證多個組中成員數量是相同的(不是強制性限制)。這主要是因為在多路複用組下，如果每個組的組成員數量相同的話，則多路複用重做日誌才可以變得對稱。雖然說在每個組中的成員數量不同，並不會對資料庫的執行造成負面影響。但是為了後續恢復以及管理的需要，筆者建議，如果採用多路複用的話，在刪除組成員時，需要考慮重做日誌檔案的對稱性問題。即最好能夠保證刪除某個組成員後，每個組的組成員數量是相同的。

　　這個數量上的限制，主要是為了保障重做日誌檔案的安全性。從某種程度來說，正是因為這個限制才確保資料庫管理員可以利用重做日誌檔案把資料恢復到故障點。為此作為資料庫管理員，必須要尊重這個限制條件，並積極的遵守它。

　　限制條件二：最好不要強制刪除重做日誌檔案組。

　　通常情況下，重做日誌檔案組對應檔案有三種狀態。如果Oracle資料庫系統不能夠訪問重做日誌檔案，則這個檔案就會變成Invalid狀態;如果Oracle資料庫系統覺得重做日誌檔案不完整或者有錯誤時，則這個重做日誌檔案就會變為許久未用狀態。當下次失效日誌檔案所屬的組變成活動組時，這個失效日誌檔案才會再次變成有效狀態。刪除重做日誌檔案組時，跟這些檔案到狀態息息相關。

　　預設情況下，重做日誌檔案組也分為兩種狀態，分別為活動狀態與非活動狀態。在刪除重做日誌檔案組時，筆者建議是先把重做日誌檔案組設定為非活動狀態。然後再進行刪除。這麼操作有一個好處就是保障重做日誌檔案組與對應的日誌檔案與控制檔案的關係。如確保更新了資料庫的相關控制檔案。不過這個限制條件跟第一個限制條件不同，並不是強制性的。如果資料庫管理員需要刪除當前的活動組，也是可以的。只是需要先強制進行日誌切換。雖然這麼做也是可行的，但是筆者強烈反對這麼操作。因為在強制進行日誌切換的過程中，如果操作不當的話，則很有可能破壞重做日誌檔案的完整性。後續出現問題時利用重做日誌檔案來恢復資料時，可能會出現問題。同理，在刪除組成員的時候，這個組成員也不能夠屬於當前組或者活動組。如故確實需要刪除某個活動組或者當前組的成員時，也是可以的，必須要先強行進行日誌切換。

　　為此，除非有特殊的必要，一定需要把當前活動的重做日誌檔案組刪除。否則的話，還是多走一步，先將重做日誌檔案組設定為非活動狀態，然後再進行刪除。這更加的保險一點。另外，在刪除聯機重做日誌檔案組之前要確保它已經歸檔。如此的話，可以保障重做日誌檔案(歸檔模式下)的完整性。當出現資料庫故障時，可以利用這個重做日誌檔案將資料庫恢復到出故障的點。無論是對於重做日誌檔案組，還是其組成員，都有這方面的要求，儘量避免對活動的組或者當前組進行刪除操作。

　　限制條件三：需要手工刪除重做日誌檔案。

　　刪除了重做日誌檔案組或者成員後，其對應的重做日誌檔案沒有被自動刪除。如在Oracle資料庫中刪除了某個重做日誌檔案組成員之後，其對應的重做日誌檔案其實並沒有從硬碟上刪除。這個刪除重做日誌檔案組成員的操作，只是更新了資料庫控制檔案中的相關內容。只有控制檔案中的這些內容被更新，重做日誌檔案組的成員才能夠被刪除。所以說，在刪除了重做日誌組成員之後，其對應的重做日誌檔案沒有被自動刪除。需要注意的是，如果把整個重做日誌組刪除，也是類似的道理。不會把整個組所使用的重做日誌檔案中硬碟中刪除，而只是為刪除的需要，更新了控制檔案中的相關內容。

為此，其實無論是刪除重做日誌檔案組還是刪除組成員，都需要分兩步走。首先就需要刪除重做日誌檔案組或者組成員。確保這第一步正確完成之後，在進行第二步。第二步就是找到這個組或者成員對應的重做日誌檔案，然後利用相關的命令來手工刪除它。雖然說不刪除的話，也沒有多少影響。但是這個重做日誌檔案往往都比較大，不過把沒用的重做日誌檔案不及時清除的話，日積月累，會越積越多。這些沒有的重做日誌檔案，不僅白白耗用了寶貴的硬碟空間，而且在恢復時有可能還會產生誤導。為此及時清除這些遺留下來的重做日誌檔案，是非常有必要的。

　　限制條件四：及時進行刪除與調整。

　　由於某些特定的原因需要進行重做檔案日誌組或者組成員刪除的，那麼可能對於時效性方面也有比較嚴格的要求。如由於硬碟介質出現故障導致某個組成員對應的重做日誌檔案無法正常儲存時，此時資料庫管理員就應該馬上調整這種狀況。先刪除這個組成員(在有必要的情況下，可能需要先建立一個組成員)，然後再刪除操作成功後再刪除對應的重做日誌檔案。如此的話，可以有效的減少由於組中的單個成員原因而導致寫入重做日誌檔案時失敗的可能性。所以，有時候對於這個清理的及時性要求也非常高。一般情況下，當重組日誌檔案寫入有錯誤時，資料庫管理員會受到來自於資料庫系統的警告資訊。此時如果資料庫管理員發現是因為硬碟介質等原因造成的寫入錯誤，則資料庫管理員需要及時進行調整。以免因小失大，導致整個重做日誌檔案失效。

　　另外，對於一個比較通用的建議，就是在刪除重做日誌檔案組或者組成員的時候，最好能夠先對重做日誌檔案進行備份。如果採用歸檔模式的話，那麼就可以直接對重做日誌檔案進行歸檔操作，讓資料庫系統自動進行備份操作。如此就可以最大限制的減少這個刪除組或者成員操作的風險。再者，就是除非有特殊的必要，最好不要輕易刪除重做日誌檔案組或者成員。因為其是跟重做日誌檔案是拴在同一個繩上的螞蚱。如果刪除了重做日誌檔案組或則成員，必定會給其對應的重做日誌檔案造成毀滅性的打擊。為此除非有特殊的必要，則最好刪除重做日誌組或者成員。有時候可以利用設定為非活動狀態來代替。不過向第四個限制條件提到的，在一些必須要刪除的情況下，資料庫管理員也不能夠手軟，要快刀斬亂麻。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-616842/，如需轉載，請註明出處，否則將追究法律責任。