這是截取自Damir Bersinic 和John Watson合著的《Oracle Database g OCP Certification AllInOne Exam Guide》書中第章Oracle出版社出版copyright McGrawHill分公司
在這章中你將會學到的是:
用控制文件挽回損失
用redo日志文件挽回損失
用系統關鍵數據文件挽回損失
用非系統關鍵數據文件挽回損失
要損壞Oracle數據是不可能的環境恢復的機制保證了這一點就是使用redo和undo來將數據庫返回到環境失敗之前的一個一致性狀態中去然而在媒介失敗之後丟失數據是可能的——如果數據庫管理員沒有予以適當的警惕
預先防范是簡單的:在歸檔日志模式下運行數據庫;多路傳送控制文件在線日志文件以及文檔日志文件;支持數據文件和文檔日志文件在媒介失敗之後備份和文檔日志可以用於恢復數據庫到失敗前的點不丟失任意一行已經被提交的數據但是盡管環境恢復的確是自動化的不可避免的——媒介恢復是一個手工的過程本章內容將會講述基本的恢復技術可以用於更加復雜問題的比較高級的技術將會在下章中涉及
不可避免性——媒介的恢復是個手工的過程本章討論的是基本的恢復技術更高級的可以應用於更加復雜問題的技術將會在稍後的章節中繼續討論
恢復結構和處理過程
在媒介失敗之後有不同的技術用於恢復根據哪個文件被損壞的情況數據庫由種文件類型組成:控制文件在線redo日志文件以及數據文件恢復控制文件和在線redo日志文件的過程是一個繁瑣的過程它們是通過多路傳送的恢復一個或者多個數據文件的過程是比較復雜的但是很直接損壞的控制文件可以通過多路傳送的拷貝或者用CREATE CONTROLFILE命令重新創建的控制文件來進行恢復在極端的情況下它可以從備份中重新存儲但是這一點在媒介失敗之後是從來不需要的如果你遵循的是一個合適的多路策略損壞的在線redo文件也可以被重新生成Oracle提供了一條ALTER DATABASE CLEAR LOGFILE GROUP #(#是損壞成員的組的號碼)命令它可以刪除並且重新創建日志文件組的成員如果數據庫運行的是文檔日志模式(也應該是這樣的)日志文件組必須在Oracle允許執行清楚日志文件命令之前進行歸檔這是因為清除一個沒有歸檔的日志文件組就意味著文檔日志流會丟失一個日志文件因此恢復就是不可能的了這樣的命令還可以有一些變化ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP #它可以刪除並重新創建日志文件即使是它沒有成功地歸檔但是在執行了這條命令之後它絕對就是執行整個數據庫備份的一個至關重要的部分
一個受到損壞的日志文件需要使用備份和文檔日志在媒介失敗導致日志文件的損壞之後有兩種選擇用於恢復:完全恢復意思是不丟失數據;還有不完全恢復這時你通過在它完成之前停止恢復過程故意丟失一部分工作不完全恢復是一個高級的程序將會在第章中講述完全恢復過程有兩個階段首先被損壞的文件必須從備份中重新存儲第二個重新存儲的文件必須被恢復通過使用文檔日志中的redo信息來把它及時地向前推進直到它與數據庫的其它部分同步
測驗貼士:在Oracle環境中重新存儲的意思是用備份替換掉一個損壞或者丟失的文件;恢復的意思是通過使用文檔日志使文件與數據庫的其它部分同步
因為在線redo日志從來沒有被RMAN備份過那麼RMAN就不能用來恢復損壞;修理由於媒介失敗導致的在線日志文件損壞可以通過SQL*Plus完成或者是通過數據庫控制控制文件和數據文件都可以通過RMAN來重新存儲或者恢復;實際上如果你把它們備份到備份集中去RMAN就是你惟一的選項
要打開一個數據庫所有的控制文件拷貝至少是每個在線日志文件組中的一個文件還有所有的在線日志文件都必須要顯示出來並且同步如果在啟動過程中SMON發現情況不對勁啟動就無法完成如果一個控制文件拷貝損壞了或者丟失了啟動就用NOMOUNT模式來終止一條描述哪個(或者哪些)拷貝被損壞了的消息就會發送給警報日志假設控制文件是好的SMON就繼續打開數據庫在這個過程中它檢查所有在線數據文件的頭如果頭有丟失或者損壞就會寫適當的錯誤消息給警報日志數據庫會繼續保持准備的模式如果所有的在線文件都顯示出來並且沒有損壞但是其中的一個或者多個沒有同步SMON會嘗試通過使用在線redo日志來對它們進行同步這就是環境恢復的過程在第章有詳細介紹這個過程是自動進行的如果所需的在線日志找不到那麼數據庫就無法打開如果一個或者多個數據文件從備份中重新存儲了那麼它們可能會非常過時在線redo日志也無法走那麼遠的時間去恢復它們:這是你就必須使用文檔日志文件來恢復了這是一個必須手工啟動的過程——從SQL*Plus中如果你用的是操作系統的命令備份的話或者使用RMAN如果(是Oracle強烈推薦的)你是用RMAN來提交備份的
如果媒介損壞發生在數據庫打開的時候那麼影響的范圍就基於有哪些文件受到影響任何控制文件拷貝的損壞都會導致數據庫環境立即終止如果受到損壞的數據文件是SYSTEM表空間或者活動的undo表空間那麼影響是一樣的但是對任何在線日志的損壞都不會導致環境的終止只要還有部分日志文件組存在的話實際上環境會繼續工作你的終端用戶也甚至不會注意到但是錯誤消息會寫到警報日志中去這種情況也需要立即糾正;這樣的糾正能夠並且應該是在線的當人們繼續工作的時候
如果損壞的數據文件時表空間的一部分而不是SYSTEM或者其他活動的undo表空間也不會導致環境的失敗但是很明顯終端用戶可能會有問題因為數據庫的部分內容消失了你的應用程序如何應對這種情況是不可預期的——它是完全根據應用程序是如何組織的對損壞數據文件的重新存儲或者恢復都可以在線完成假如它們不是屬於SYSTEM或者undo表空間的數據文件最後如果是組成你的臨時表空間的臨時文件受到損壞終端用戶也完全不會注意到Oracle不會去驗證臨時文件的存在除非要使用它們了並且一個經過良好調整的數據庫也許永遠也不會用到它們這就是說臨時文件可以在它們受到注意之前消失一陣子同樣也意味著損壞的臨時文件可以被刪除或者重新創建在任何時間除非正好在那個時候要用到它
在備份中重新存儲可以通過RMAN或者操作系統工具來完成但是如果你的RMAN備份是備份集合而不是映像的拷貝重新存儲就只能通過RMAN來完成了:沒有其他的方法從數據集中解壓縮數據文件重新存儲後的恢復也可以通過SQL*Plus命令或者用RMAN來完成但是也有同樣的約束條件:只有RMAN可以從備份集中解壓縮文檔日志
從媒介失敗中恢復
媒介失敗之後的重新存儲和恢復在下一章中會進行更加詳細的描述並且在第二個OCP考試中也會詳細考察但是了解一下初級考試中的簡單問題的基本恢復也是很有必要的這些簡單的問題是丟失了多路控制文件中的一個和一個在線redo日志文件以及關鍵和非關鍵數據文件丟失之後的完全恢復
多路控制文件丟失的恢復
只要挽救了現有控制文件的多路拷貝恢復損失的控制文件就是簡單的只要用挽救回來的控制文件的拷貝替換它就可以了要從備份中重新存儲被損壞的或者丟失的控制文件拷貝在這樣的情況下是沒有用處的因為控制文件的所有的拷貝都必須是同樣的;很明顯一個重新存儲的拷貝不會與其他幸存的拷貝同步更不用說是數據庫的其它部分了
實際上在損壞發生的瞬間環境就會終止而像往常一樣數據庫管理員的第一個反應就是壞了的環境應該重新啟動在NOMOUNT模式下這不會成功的並且會返回一個錯誤消息警報日志將會描述哪個控制文件拷貝丟失了還會在這個部分列出那些非默認情況的初始化參數——實際上使用了多少控制文件以及它們都在哪裡在這一點上你要注意三點第一點你需要編輯參數文件來刪除對丟失或者損壞的控制文件的參考
這樣很好但是你的數據庫現在就要運行就會少了一部分多路拷貝這有可能會違反你的安全條款一個更好的選擇就是用幸存下來的拷貝來替換損壞的文件或者真的去更改CONTROL_FILES初始化參數來刪掉對那些被損壞的文件的參考重新參考一些新的文件然後拷貝那些幸存的控制文件到那裡去
測驗貼士:恢復控制文件的丟失是必須要承擔停機時間的它無法在線完成
測驗:從控制文件的丟失中恢復
在這個測驗中假設你丟失了多路控制文件並且要用一個拷貝來替換它
用SQL*Plus連接到你的數據庫上去然後確保你的控制文件是多路傳輸到這個查詢的:
SQL> select * from v$controlfile;
這個查詢必須返回至少行如果沒有的話多路傳輸你的控制文件
假設你的數據庫受到攻擊一個控制文件損壞了並且你的一個控制文件名字更改了注意在Windows上你必須首先停止Windows服務否則Windows不會讓你更改文件名然後再重新啟動這個服務
輸入啟動命令這次啟動會終止在nomount模式並且返回ORA: error in identifying controlfile check alert log for more info錯誤消息
拷貝幸存的控制文件到你重新命名的文件路徑上去名字也改為你重新設定的名字
再次輸入啟動命令這次就會成功了
問題示例:
丟失這些文件會導致打開的數據庫崩潰?(項選擇)
一個多路控制文件
一個多路在線日志文件
一個多路文檔日志文件
一個活動的undo表空間數據文件
一個活動的臨時表空間臨時文件
一個SYSAUX表空間中的數據文件
一個SYSTEM表空間中的數據文件
一個包含了關鍵用戶數據的數據文件
一個多路控制文件的拷貝損壞你應該怎麼做?(單選)
用幸存的拷貝替換
用RMAN重新存儲
用操作系統命令重新存儲
用CREATE CONTROLFILE命令重新創建
From:http://tw.wingwit.com/Article/program/Oracle/201311/17681.html
