4.手工備份恢復--關閉數據庫的完全和不完全恢復(練習3、4)
練習3:完全數據庫恢復
我們要實現恢復到出數據庫出問題的時間點,必須先把數據庫設置成歸檔模式。在接下的步驟中首先將設置數據庫為歸檔模式,然后生成歸檔日志文件,最后在數據庫崩潰的時候,利用歸檔日志文件把數據庫恢復到發生問題的時間點。
步驟一:配置數據庫歸檔模式
首先說明一下什么叫歸檔,歸檔就是把聯機重做日志文件復制到歸檔重做日志文件的過程叫歸檔。下面我們通過v$database視圖,查看PRACTICE數據庫是否處于歸檔模式下:

數據庫標示符(dbid)是數據庫創建時Oracle分配的一個唯一編號,從log_mode查詢的結果可以看出PRACTICE數據庫并沒有處于歸檔模式,因此數據庫切換到下一個重做日志文件時,Oracle將覆蓋前一個重做日志中的事務,聯機重做日志文件中的重做變化信息一旦被覆蓋,就不能被使用。
在設置歸檔模式之前,我們先熟悉并設置三個相關的參數:
- Archive Destination(歸檔目的地址) 動態參數,通過在參數文件中加入如下行,告知數據庫把歸檔重做日志文件存放在什么位置:
ALTER SYSTEM SET log_archive_dest=” D:\oracle\PRACTICE\ARCHIVE”; ,歸檔文件可以被拷貝到多個目錄中(最多5個)。 - Archive Format(歸檔文件名格式)靜態參數,在參數文件中可以指定歸檔文件的命名約定,默認格式ARC%S_%R.%T,可以通過
ALTER SYSTEM SET log_archive_format=”ARC%S_%R.%T” SCOPE=SPFIlE; 設置,每當聯機重做日志切換時,就產生一個新的序號。 - Archive Start(歸檔啟動)在Oracle 10g該參數被廢除,在配置參數文件中將不需設置,該參數只要在數據庫啟動設置,這個值將持續到下一次修改,這個過程中無論發生多上次重啟都沒關系。這就避免了Oracle10g之前,啟動時調整該參數值,而沒有修改參數文件的值,下次啟動時又恢復至未修改的狀態。


修改完畢后,關閉數據庫,以MOUNT方式啟動,
2 SQL>STARTUP MOUNT;
3 SQL>ALTER DATABASE ARCHIVELOG;

打開數據庫后,每次當前日志文件切換時,都會在歸檔目的路徑下生成一個文件。下面我們運行一些命令來驗證參數設置是否起作用了,可以查看視圖v$archive_dest中的內容,檢查歸檔路徑是否正確。

如果狀態為(Valid)意味著正確初始化目的路徑,下面使用顯示參數命令(show parameter),來查看任何一項參數設置:
2 SQL>SHOW PARAMETER log_archive_format

另一個用于查看歸檔信息的SQL*Plus命令是歸檔日志列舉命令(archive log list):

在參數文件設置已經起作用,打開數據庫

當前數據庫活動不多,很難填滿當前聯機重做日志文件,可以使用ALTER SYSTEM命令進行手工切換日志文件。

步驟二:運行備份腳本
利用練習1的腳本進行數據庫備份,具體步驟參見練習1步驟三。Oracle推薦在數據庫設置為ARCHIVE LOG模式后進行完整的數據庫備份,使用整體一致的數據庫備份和所有歸檔日志文件的拷貝,能夠把數據庫恢復到任何時間點上。
步驟三:生成重做日志
在TINA.DATE_LOG插入行,生成數據庫活動記錄,然后強制進行日志切換,在后續的步驟將需要至少一個歸檔日志文件。執行強制日志文件時,會在警告日志文件中看到如下內容

步驟四:刪除一個數據文件
關閉數據庫,然后刪除USERS01.DBF文件,當打開數據庫時,看到如下信息:


步驟五:還原丟失的數據文件
我們以SHUTDOWN ABORT關閉數據庫(后續的練習中將會講述數據庫打開時恢復),然后啟動數據庫,提示步驟四的出錯信息,我們查看v$recover_file內容:

從步驟二所做的備份目錄下復制USERS01.DBF文件到當前數據庫文件路徑,此時再查看v$recover_file視圖,該錯誤項不存在,change#列有一個數據值。該數值與v$datafile視圖中對應所有文件的檢查點變化數值進行比較,將會看到v$datafile視圖中SCN要比v$recover_file中的數值大,除非對應所有聯機數據文件的SCN與數據文件頭部以及控制文件相同,否則無法打開數據庫。

步驟六:恢復還原的數據文件
為了使所有的數據文件擁有一直的SCN號,需要應用歸檔重做日志文件,使用如下命令:

使用該命令,Oracle確定哪個數據文件被恢復以及需要哪個重做日志文件。當恢復成功,系統將提示成功:Media recovery complete。
以下說明非必要,但有助于確認歸檔重做日志文件范圍,使用如下語句查看歷史歸檔和當前聯機重做日志信息
2 SQL>SELECT * FROM v$log;

完成恢復后,查看v$recover_file的內容,沒有任何返回行,表明USERS01.DBF所需的重做信息均已被采用,打開數據庫,如下圖顯示:

步驟七:確認數據庫已恢復
檢查TINA.DATE_LOG中的數據最新的日期/時間值,應該在刪除數據文件之前,如果存在則表示,成功地進行一次完全數據庫恢復!

練習4:不完全數據庫恢復
所謂不完全恢復是把數據庫回退到某一時間點,在恢復的過程中使用部分(而非所有的)歸檔重做日志文件。在如下情況需要進行不完全數據恢復:
- 由于失誤而刪除數據庫對象
- 丟失部分或全部聯機重做日志
- 在恢復過程中丟失了一個已歸檔的重做日志
- 錯誤地刪除表空間
當使用不完全恢復數據庫時,通過以RESETLOGS選項打開數據庫,一旦數據庫打開被忽略的重做信息就不能再使用。重置日志文件創建數據庫的一個新實體,數據庫的SCN號將以新的日志序列流開始,其實的日志序號為1。
在下面的練習中,刪除TS4DROP表空間(因為刪除表空間會向告警日志寫入一條消息,可以通過該消息定位恢復時間點),然后恢復數據庫到誤操作發生前的時間點。
步驟一:刪除表空間
這里將設置一個不完全恢復的環境,最好的方法先在TINA.DATE_LOG表中插入一筆三十年后的數據,并進行至少3次強制日志切換,然后刪除PRACTICE數據庫中的TS4DROP表空間,這樣恢復中將使用已歸檔的日志,而不是聯機日志。
2 SQL>SELECT create_date FROM tina.date_log;

為刪除TS4DROP表空間,使用如下命令:
2 SQL>ALTER SYSTEM SWITCH LOGFILE;

執行命令后查看v$tablespace視圖,TS4DROP表控件已經被刪除

步驟二:確認恢復時間點
在實際工作中,DBA可能并不知道事故發生的準確時間,由于本練習是刪除表空間,可以從告警日志定位發生問題的時間點,而對于對象變動,如:刪除表需要使用LogMiner找出更精確的時間(將在后續的練習介紹)。
在告警日志文件中,找出刪除表空間的記錄:

記錄顯示在2010-01-12 07:48:03時間執行了刪除表空間命令,該命令在1秒內執行完畢,在該命令之前,告警日志發生了一次日志切換。對應當前日志序號為28,可以使用如下語句查看日志序號28的相關信息:

由此我們得知在2010-1-12 07:48:03執行了一次刪除表空間的操作,當前的重做日志序號為28,其變更號從518720開始,這些信息對于不完全恢復是關鍵的,因為通過這些信息我們可以將不完全恢復進行到某一時間點、某一數據庫更改號或者某一特定的日志文件上。
步驟三:還原數據文件和控制文件
在進行不完全恢復需關閉數據庫,從練習3中復制所有數據庫文件和控制文件到當前數據庫所在位置,注意的是當前聯機重做日志需保留,因為可能需要聯機重做日志文件中的重做信息,將數據庫恢復到表空間被刪除之前的時間點。

步驟四:不完全恢復數據庫
使用ALTER DATABASE命令恢復數據庫,有恢復到某一特定的時間、更改號或重做日志文件三種方式:
- 基于時間的恢復 通過指定時間參數可以把數據庫恢復到制定時間點,日期必須符合yyyy-MM-dd HH24:mi:ss格式的字符。
SQL> ALTER DATABASE RECOVER AUTOMATIC UNTIL TIME '2010-01-12 07:48:02'; - 基于變化的恢復 指定一個SCN值用于恢復,該方法是三種方法最為準確
SQL> ALTER DATABASE RECOVER AUTOMATIC UNTIL SCN 518720; - 基于取消的恢復 使用CANCEL關鍵字,執行不完全數據庫恢復。重做日志是一個接一個應用直到對應時間點的那個重做日志文件。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
以MOUNT啟動數據庫,使用基于時間的恢復(需要注意是恢復的時間,比刪除表空間提前一點,這里是提前一秒為2010-01-12 07:48:02),具體命令如下:

步驟五:以重置日志選項打開數據庫
完成不完全恢復后,必須重新設置聯機重做日志,當使用RESETLOGS選項打開數據庫時,所有數據庫文件都獲得一個新的RESETLOGS SCN和時間戳。為了打開數據庫并重新設置日志,可以使用如下命令:

執行后聯機重做日志文件被還原,每個數據文件頭被更新,控制文件而被更新,所有這些工作完成后,數據庫打開。

可以看到日志文件再次開始計數。
步驟六:確認數據庫恢復
恢復完成后,可以查看v$tablespace視圖來查看數據庫中是否包括TS4DROP表空間;檢查TINA.DATE_LOG表看是否存在刪除表空間前插入那筆三十年之后的記錄,丟失了刪除表空間后插入該表的數據。

如果結果和你想象的一樣,恭喜你成功地進行了不完全恢復!


浙公網安備 33010602011771號