雖然重做日志文件非常的重要但是有時候數據庫管理員仍然需要忍痛割愛將某些重做日志文件組或者組成員刪除如當硬盤出現物理損壞此時就無法往這個位置存放重做日志此時為了避免重做日志的錯誤就需要將其刪除然後再新建一個重組日志組成員等等所以有時是刪除只是為了其更需更好的工作而已但是刪除重做日志文件組或者其成員畢竟不是一件簡單的工作在做這個操作的時候數據庫管理員需要注意幾個限制條件
限制條件一數量上的限制
通常情況下Oracle數據庫系統治少需要兩個重做日志文件組如果數據庫系統中只有兩個重做日志文件組而出於某種原因數據庫管理員需要刪除其中的一個重做日志文件組則數據庫會拒絕這個操作如故確實有必要需要刪除這個重做日志文件組那麼數據庫管理員必須先新建一個重組日志文件組然後再把需要刪除的日志文件組刪除這是Oralce數據庫對於重做日志文件組數量上的限制作為數據庫管理員必須無條件的遵守
另外對於組成員來說也有類似的限制每個重做日志文件組必須要有一個有效的成員如因為硬盤介質錯誤等原因需要把唯一的一個組成員刪除此時Oracle數據庫系統會提示錯誤信息拒絕類似的操作此時數據庫系統如果仍然像保留這個重做日志文件組則只好先建立一個組成員或者將某個失效的組成員設置為有效然後再刪除不起作用的組成員其次需要說明的是如果在重做日志文件中采用多路復用組的話則最好還要保證多個組中成員數量是相同的(不是強制性限制)這主要是因為在多路復用組下如果每個組的組成員數量相同的話則多路復用重做日志才可以變得對稱雖然說在每個組中的成員數量不同並不會對數據庫的運行造成負面影響但是為了後續恢復以及管理的需要筆者建議如果采用多路復用的話在刪除組成員時需要考慮重做日志文件的對稱性問題即最好能夠保證刪除某個組成員後每個組的組成員數量是相同的
這個數量上的限制主要是為了保障重做日志文件的安全性從某種程度來說正是因為這個限制才確保數據庫管理員可以利用重做日志文件把數據恢復到故障點為此作為數據庫管理員必須要尊重這個限制條件並積極的遵守它
限制條件二最好不要強制刪除重做日志文件組
通常情況下重做日志文件組對應文件有三種狀態如果Oracle數據庫系統不能夠訪問重做日志文件則這個文件就會變成Invalid狀態;如果Oracle數據庫系統覺得重做日志文件不完整或者有錯誤時則這個重做日志文件就會變為許久未用狀態當下次失效日志文件所屬的組變成活動組時這個失效日志文件才會再次變成有效狀態刪除重做日志文件組時跟這些文件到狀態息息相關
默認情況下重做日志文件組也分為兩種狀態分別為活動狀態與非活動狀態在刪除重做日志文件組時筆者建議是先把重做日志文件組設置為非活動狀態然後再進行刪除這麼操作有一個好處就是保障重做日志文件組與對應的日志文件與控制文件的關系如確保更新了數據庫的相關控制文件不過這個限制條件跟第一個限制條件不同並不是強制性的如果數據庫管理員需要刪除當前的活動組也是可以的只是需要先強制進行日志切換雖然這麼做也是可行的但是筆者強烈反對這麼操作因為在強制進行日志切換的過程中如果操作不當的話則很有可能破壞重做日志文件的完整性後續出現問題時利用重做日志文件來恢復數據時可能會出現問題同理在刪除組成員的時候這個組成員也不能夠屬於當前組或者活動組如故確實需要刪除某個活動組或者當前組的成員時也是可以的必須要先強行進行日志切換
為此除非有特殊的必要一定需要把當前活動的重做日志文件組刪除否則的話還是多走一步先將重做日志文件組設置為非活動狀態然後再進行刪除這更加的保險一點另外在刪除聯機重做日志文件組之前要確保它已經歸檔如此的話可以保障重做日志文件(歸檔模式下)的完整性當出現數據庫故障時可以利用這個重做日志文件將數據庫恢復到出故障的點無論是對於重做日志文件組還是其組成員都有這方面的要求盡量避免對活動的組或者當前組進行刪除操作
限制條件三需要手工刪除重做日志文件
刪除了重做日志文件組或者成員後其對應的重做日志文件沒有被自動刪除如在Oracle數據庫中刪除了某個重做日志文件組成員之後其對應的重做日志文件其實並沒有從硬盤上刪除這個刪除重做日志文件組成員的操作只是更新了數據庫控制文件中的相關內容只有控制文件中的這些內容被更新重做日志文件組的成員才能夠被刪除所以說在刪除了重做日志組成員之後其對應的重做日志文件沒有被自動刪除需要注意的是如果把整個重做日志組刪除也是類似的道理不會把整個組所使用的重做日志文件中硬盤中刪除而只是為刪除的需要更新了控制文件中的相關內容
為此其實無論是刪除重做日志文件組還是刪除組成員都需要分兩步走首先就需要刪除重做日志文件組或者組成員確保這第一步正確完成之後在進行第二步第二步就是找到這個組或者成員對應的重做日志文件然後利用相關的命令來手工刪除它雖然說不刪除的話也沒有多少影響但是這個重做日志文件往往都比較大不過把沒用的重做日志文件不及時清除的話日積月累會越積越多這些沒有的重做日志文件不僅白白耗用了寶貴的硬盤空間而且在恢復時有可能還會產生誤導為此及時清除這些遺留下來的重做日志文件是非常有必要的
限制條件四及時進行刪除與調整
由於某些特定的原因需要進行重做文件日志組或者組成員刪除的那麼可能對於時效性方面也有比較嚴格的要求如由於硬盤介質出現故障導致某個組成員對應的重做日志文件無法正常保存時此時數據庫管理員就應該馬上調整這種狀況先刪除這個組成員(在有必要的情況下可能需要先建立一個組成員)然後再刪除操作成功後再刪除對應的重做日志文件如此的話可以有效的減少由於組中的單個成員原因而導致寫入重做日志文件時失敗的可能性所以有時候對於這個清理的及時性要求也非常高一般情況下當重組日志文件寫入有錯誤時數據庫管理員會受到來自於數據庫系統的警告信息此時如果數據庫管理員發現是因為硬盤介質等原因造成的寫入錯誤則數據庫管理員需要及時進行調整以免因小失大導致整個重做日志文件失效
另外對於一個比較通用的建議就是在刪除重做日志文件組或者組成員的時候最好能夠先對重做日志文件進行備份如果采用歸檔模式的話那麼就可以直接對重做日志文件進行歸檔操作讓數據庫系統自動進行備份操作如此就可以最大限制的減少這個刪除組或者成員操作的風險再者就是除非有特殊的必要最好不要輕易刪除重做日志文件組或者成員因為其是跟重做日志文件是拴在同一個繩上的螞蚱如果刪除了重做日志文件組或則成員必定會給其對應的重做日志文件造成毀滅性的打擊為此除非有特殊的必要則最好刪除重做日志組或者成員有時候可以利用設置為非活動狀態來代替不過向第四個限制條件提到的在一些必須要刪除的情況下數據庫管理員也不能夠手軟要快刀斬亂麻
From:http://tw.wingwit.com/Article/program/Oracle/201311/16607.html