Oracle 備份與 恢復 概述

gunguymadman

版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://sds07s7.blogbus.com/logs/62548066.html

　　玩Oracle也有2年的時間了， 零零散散的也整理一些資料。 東西一多了，就理不清楚。 所以結合張曉明的《大話Oracle RAC》的一些內容，和自己整理的一些筆記，對Oracle 的備份和恢復做了一個系統(tǒng)的整理。 也是自己對知識的一個鞏固吧。


一． 準備知識

　　先來看一些準備知識，了解Oracle的物理結構，有如下4種。


1. 數(shù)據(jù)文件和數(shù)據(jù)塊

　　Oracle 數(shù)據(jù)庫的存儲空間是用表空間來表示的，表空間只是一個邏輯概念，而物理上每個表空間是由磁盤文件組成，這些文件叫做數(shù)據(jù)文件（Data file），每個表空間可以由一個到多個數(shù)據(jù)文件組成，每個數(shù)據(jù)文件被劃分為若干個最小的存儲單位： 數(shù)據(jù)塊（data block）。

　　具體參考我的blog： 表空間(tableSpace) 段(segment) 盤區(qū)(extent) 塊(block) 關系

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 2/13/4962476.aspx

　　Oracle 的用戶數(shù)據(jù)是寫到數(shù)據(jù)塊上的，Oracle 是在SGA上操作數(shù)據(jù)的，修改數(shù)據(jù)或者添加數(shù)據(jù)都是在內存中進行，這些被修改的內存不會立即寫入磁盤，而是以特定的時間間隔被寫入磁盤。 如果哦數(shù)據(jù)庫正常關閉，則在關閉之前將內存中的數(shù)據(jù)同步到磁盤，這時數(shù)據(jù)狀態(tài)是一致的。如果數(shù)據(jù)庫不正常關閉（如宕機，shutdown abort），內存中的內容沒有完全寫回磁盤，這時數(shù)據(jù)文件是不一致的。 如果數(shù)據(jù)文件是從備份中恢復出來的，數(shù)據(jù)文件也是不一致的，不一致性的數(shù)據(jù)文件必須恢復到一致的狀態(tài)。


2. 日志文件

　　Oracle 數(shù)據(jù)庫日志文件包括 聯(lián)機日志 和 歸檔日志， 這些文件都是用來記錄數(shù)據(jù)庫修改歷史的。Oracle 數(shù)據(jù)庫至少要有兩組聯(lián)機日志，聯(lián)機日志循環(huán)使用，當一組聯(lián)機日志寫滿后，就要切換到另一組聯(lián)機日志，后者的內容就會被覆蓋，這個過程叫作日志切換（Log Switch），在日志切換時會觸發(fā)檢查點（CheckPoint）。

　　數(shù)據(jù)庫的修改操作要記錄到日志文件中，并且這個記錄動作是在修改數(shù)據(jù)之前進行的，正因為日志文件中記錄了所有的修改歷史，因此如果有過去某個時點的備份文件，并且有從那是到當前的所有日志文件，就可以通過在備份文件上"重演"這些日志的方式，把數(shù)據(jù)文件恢復到當前狀態(tài)或者之間的任何時點的狀態(tài)。


日志線程（Redo Thread）：

　　每個實例用到的聯(lián)機日志就是一個Redo Thread，單實例有且僅有一個Redo Thread。在RAC 環(huán)境下，每個實例都需要自己的聯(lián)機日志，也就是每個實例都有自己的Redo Thread。 這種每實例一個Redo Thread的設計就是為了避免實例間共享Redo 文件引發(fā)的競爭，提高系統(tǒng)性能。 但是這也帶了一個問題，就是用RMAN 備份RAC 的時候，需要所有的日志文件。 故需要在兩個節(jié)點上互相把日志傳送到另一個節(jié)點。

　　Thread 這個參數(shù)用來指定實例使用的Redo Thread 線程號。一般和該實例的INSTANCE_NUMBER 參數(shù)相同。 通過視圖V$LOG的Thread#列可以確定日志組所屬的線程。

　　注意： 因為RAC 環(huán)境下有多個日志線程，所以在添加日志時必須指定線程號。

　　SQL>alter database add logfile thread 1 group 5 ('/oracle/oradata/redo5') size 50m;

　　在RAC 環(huán)境下，用戶操作是分布在多個實例之間的，各實例都有自己的聯(lián)機日志，恢復時必須把所有實例的聯(lián)機日志都合并，把Redo Log Record 按照SCN 排序，才能整理出準確的用戶操作記錄，所以RAC的聯(lián)機日志必須放在共享存儲上，以保證實例都能訪問其他實例的聯(lián)機日志。

　　在看一個sql 的查詢結果：

　　SQL> select * from v$log;

　　GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS

　　---------- ---------- ---------- ---------- ---------- --- ---------------- ----

　　1 1 24585 104857600 1 YES ACTIVE

　　2 1 24583 104857600 1 YES INACTIVE

　　3 1 24584 104857600 1 YES INACTIVE

　　8 1 24586 104857600 1 NO CURRENT

　　從查詢結果上，我們可以看到聯(lián)機日志有3個狀態(tài)。

　　INACTIVE: 表示DBWR 已經做完，該日志包含的數(shù)據(jù)修改已經寫到數(shù)據(jù)文件

　　ACTIVE: DBWR 沒有做完，數(shù)據(jù)還沒有寫到數(shù)據(jù)文件。

　　CURRENT：當前正在使用的日志。 沒有DBWR 操作。

　　RedoLog Checkpoint 和 SCN關系

　　http://blog.csdn.net/tianlesoftware/archive/2010/0 1/25/5251916.aspx

　　Redo Log 和Checkpoint not complete

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 2/01/4908066.aspx

　　Oracle 歸檔與非歸檔的切換

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 0/19/4693470.aspx

　　log file sync(日志文件同步) 與 Log file parallel write 等待事件

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 2/02/4916671.aspx


3. 控制文件

　　控制文件記錄了數(shù)據(jù)庫的物理結構和狀態(tài)（比如數(shù)據(jù)文件名，每個數(shù)據(jù)文件的檢查點號，聯(lián)機狀態(tài)），包括備份和恢復的信息也記錄在控制文件中。 恢復過程要根據(jù)控制文件中的信息，比如數(shù)據(jù)庫的檢查點，當前聯(lián)機日志，數(shù)據(jù)文件檢查點等來進行恢復操作，如果控制文件丟失，則恢復的過程會很艱難。

　　控制文件里包含的具體信息，參考我的Blog：

　　Oracle 控制文件

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 2/13/4974440.aspx 4. Undo Segment修改記錄過程中，記錄修改之前的狀態(tài)會被記錄到Undo Segment中， 這條記錄叫作前鏡像（before images）。 當需要撤銷修改比如執(zhí)行Rollback時，就用這條前鏡像覆蓋現(xiàn)有記錄，對于Insert 操作，前鏡像就是一個空記錄，對于Undate，Delete 操作，前鏡像就是修改之前的記錄。

　　在數(shù)據(jù)庫恢復過程中，日志和Undo Segment 共同起作用，二者保證了最終恢復的一致狀態(tài)。二者也對應了恢復的兩個階段： 前滾（Roforware）和 回滾（Rollback）。在前滾階段，在文件上重演日志內容，以把文件恢復到數(shù)據(jù)庫關閉時的狀態(tài)，但是數(shù)據(jù)庫關閉時可能有很多修改操作沒有提交，這些操作必須進行回滾，這就要利用Undo Segment的內容。

　　Oracle undo 回滾段管理

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 1/30/4901666.aspx


二．備份

　　備份是指數(shù)據(jù)的拷貝，這個拷貝可以用來重建數(shù)據(jù)庫。 備份可以分為物理備份和邏輯備份。

　　物理備份： 指對數(shù)據(jù)文件，控制文件，聯(lián)機日志文件等文件進行物理拷貝的方法，這種方法是在文件層進行的，通過冗余的文件備份來體統(tǒng)數(shù)據(jù)保護。物理備份又可分為聯(lián)機備份（也叫作聯(lián)機熱備）和脫機備份（也稱冷備）。

　　邏輯備份： 利用Oracle 提供的導出工具把重要數(shù)據(jù)導出到文件，以后恢復時在利用工具把數(shù)據(jù)重新導入到數(shù)據(jù)庫中，這種保護是在數(shù)據(jù)層進行的。 該類工具有： exp/imp, expdp/impdp（10g 以后版本）。

　　物理備份是最強健的數(shù)據(jù)保護方也，也是備份策略中首選的方法，邏輯備份只能作為物理備份的補充手段，不足以保護數(shù)據(jù)丟失。

　　物理備份又可分為用戶管理備份（User-Managed Backup）和RMAN備份（Recovery Manager）。 前者是聯(lián)合使用SQL 命令和OS的cp 命來進行文件備份。 Rman 備份指利用RMAN 工具來進行備份。

　　Rman 備份有幾點好處：

　　1. 增量備份

　　2. 數(shù)據(jù)塊恢復：可以在新進行數(shù)據(jù)塊恢復，不必進行數(shù)據(jù)文件恢復，提高系統(tǒng)的可用性。

　　3. 壓縮備份

　　4. 加密備份

　　具體用法參考blog：

　　RMAN 備份與恢復 實例

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 0/20/4699320.aspx

　　Oracle Rman 命令詳解(List report backup configure)

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 2/13/4976998.aspx

　　Oracle Rman跨resetlogs版本恢復

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 0/17/4682463.aspx

　　ORACLE 數(shù)據(jù)庫邏輯備份 簡單 EXP/IMP

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 0/24/4718366.aspx

　　Oracle 10g EXPDP和IMPDP使用說明

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 0/16/4674224.aspx


三．恢復


3.1 理論知識：

　　Oracle 在運行過程中，所有對于數(shù)據(jù)的修改都是在內存中進行，Oracle 每要修改一個記錄必須先把記錄所在的數(shù)據(jù)塊加載到內存中，然后在內存中進行修改。但是提交（commit）時，修改的數(shù)據(jù)塊不會立即寫回磁盤�；�于性能考慮，Oracle是采用"延時寫"的算法定期批量的把數(shù)據(jù)塊寫回磁盤。因此在數(shù)據(jù)庫運行過程中，內存的內容總是比磁盤數(shù)據(jù)新。 當數(shù)據(jù)庫正常關閉時（Shutdown Immediate,shutdown normal,shutdown tracsactional）,Oracle 會把SGA內容全部寫回磁盤后才關閉數(shù)據(jù)庫，這時內存和磁盤就完全同步了。 所以正常關閉數(shù)據(jù)庫后數(shù)據(jù)不會丟失，但是如果數(shù)據(jù)庫是異常關閉（突然短線，shutdown abort），內存中的數(shù)據(jù)來不及同步到磁盤，這是就會產生了數(shù)據(jù)不一致，Oracle 在次打開數(shù)據(jù)庫時，就需要進行實例恢復。

　　Oracle 的Redo 機制保證了數(shù)據(jù)庫恢復的可行性，在修改數(shù)據(jù)之前，代表本次修改操作的Redo記錄必須先被保存下來（Write Ahead Logging），然后才真正修改數(shù)據(jù)記錄。在處理commit語句時，Oracle 會在Log buffer產生一條commit 記錄，為了保證事務的持久化，所有Redo 記錄和這一條commit記錄都要被寫到磁盤的聯(lián)機日志文件（Log Force At commit），但是數(shù)據(jù)塊（Data Block）不必寫回磁盤。 如果聯(lián)機日志空間不夠，還會觸發(fā)日志切換（Log Switch），舊日志的檢查點必須完成才能被覆蓋，如果采用歸檔模式，這個日志還必須完成歸檔才能覆蓋。

　　這些日志中都會帶有SCN，SCN類似于時間戳，Oracle 按照SCN對日志內容進行排序，就可以得到操作歷史，Oracle 也是根據(jù)SCN來判斷數(shù)據(jù)文件是否需要恢復的。

　　數(shù)據(jù)庫在正常運行時，每個數(shù)據(jù)文件的終止SCN(STOP SCN)會被設置為無窮大（NULL），而其他的那些SCN應該完全一樣。如果數(shù)據(jù)庫正常關閉，關閉之前會執(zhí)行一個檢查點動作，每個數(shù)據(jù)文件的終止SCN 會被設置成啟動SCN（Start SCN）。 如果數(shù)據(jù)庫異常關閉，終止SCN 來不及設置為啟動SCN，仍然保持NULL。

　　當clean shutdown 時，checkpoint會進行，并且此時datafile的stop scn和start scn會相同。 等到我們開啟數(shù)據(jù)庫時，Oracle檢查datafile header中的start scn和存于control file中的datafile的scn是否相同， 如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，數(shù)據(jù)庫就會正常開啟，否則就需要recovery... 等到數(shù)據(jù)庫開啟后，儲存在control file中的stop scn就會恢復為NULL值，此時表示datafile是open在正常模式下了。

　　如果不正常SHUTDOWN (shutdown abort)，則mount數(shù)據(jù)庫后，你會發(fā)現(xiàn)stop scn并不是等于其它位置的scn， 而是等于NULL，這表示Oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery。

　　注意：當發(fā)生checkpoint時，會把SCN寫到四個地方去。三個地方于control file內，一個在datafile header。

　　Control file三個地方為

　　1.System checkpoint SCN

　　2.2.Datafile checkpoint SCN

　　3.Stop SCN 另外一個地方在datafile header內

　　4.Start SCN

　　更多內容參看blog： RedoLog Checkpoint 和 SCN關系 http://blog.csdn.net/tianlesoftware/archive/2010/0 1/25/5251916.aspx Oracle恢復可以分成實例恢復（Instance Recovery）,介質恢復（Media Recovey），其中介質恢復又可分為完全恢復（Complete Recovery）和不完全恢復（Incomplete Recovery）。

gunguymadman

3.2 恢復種類

　　3.2.1 Instance Recovery -- 由Oracle 自動完成，無需DBA 干預

　　如果實例異常關閉（宕機，shutdown abort），并且數(shù)據(jù)文件，控制文件，聯(lián)機日志都沒有丟失。在下次啟動時，要利用聯(lián)機日志的內容進行恢復，這種恢復就是實例恢復（Instance Recovery）。

　　Instance Recovery 主要包括3個階段：

　　1） 根據(jù)聯(lián)機日志內容進行Rollover。

　　2） 打開數(shù)據(jù)庫，提供服務

　　3） SMON 或者用戶進程進行Rollback。

　　3.2.2 Media Recovery

　　如果發(fā)生數(shù)據(jù)文件丟失或者破壞，就需要使用備份和歸檔日志來進行恢復， 這種恢復就是 介質恢復，它需要有備份，歸檔日志，聯(lián)機日志一起才能完成。又分為 安全恢復和不完全恢復兩種。

　　3.2.3 Crash Recovery -- 由Oracle 自動完成。

　　Instance Recovery是實例發(fā)生Crash 后進行的Recovery，這種恢復是在故障節(jié)點進行，而RAC 中的Crash Recovery 是某個實例發(fā)生Crash 后在其他實例上進行的Recovery。 這種Recovery 有一個特殊要求：在健康節(jié)點執(zhí)行Crash Recovery時，必須要保證故障節(jié)點不能在對共享數(shù)據(jù)進行操作，也就是要對故障節(jié)點進行IO 隔離（IO Fencing），這是由CSS服務來保證的。

　　在Crash Recovery過程中PCM Lock起到了重要作用，恢復實例（執(zhí)行Recovery動作的實例）根據(jù)數(shù)據(jù)塊的PCM-Lock 狀態(tài)來決定數(shù)據(jù)塊是否需要進行恢復。

　　Crash Recovery 可分為3個階段：

　　1）First-Pass Log Read

　　2）Recovery Claim Locking

　　3）Second-Pass Log Read

　　3.2.4 Online Block Recovery

　　Online Block Recovery 是RAC所特有的， 如果某個用戶進程在修改數(shù)據(jù)時異常死掉，導致SGA的Data buffer數(shù)據(jù)不一致，或者說Data Buffer被破壞，這時就會觸發(fā)Online Block Recovery，這個動作可有PMON進程或者前臺進程完成。這個恢復過程需要一個恢復起點， 這個起點就是最近的Past Image。


3.3 介質恢復

　　介質恢復指磁盤介質發(fā)生損壞，導致數(shù)據(jù)文件無法訪問，這時必須利用備份文件在新的磁盤上恢復出數(shù)據(jù)文件。

　　3.3.1 完全恢復

　　它是把數(shù)據(jù)庫恢復到發(fā)生故障時的狀態(tài)，名字中的完全指沒有任何數(shù)據(jù)損失，要實現(xiàn)這個目標，必須滿足一定的條件： 備份，從備份之后的所有歸檔日志，聯(lián)機日志都可用。

　　完全恢復是最簡單的一種恢復， 只需要兩個命令： restore database 和 recover database。

　　這2個命令的具體用法參考我的Blog： RMAN 備份與恢復 實例， 里面有詳細的例子

　　http://blog.csdn.net/tianlesoftware/archive/2009/1 0/20/4699320.aspx

　　在次補充一點知識： RECOVER DATABASE UNTIL CANCEL 和 RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE區(qū)別

　　1） RECOVER DATABASE UNTIL CANCEL

　　==> DATAFILE HEADER SCN一定會小于CONTROLFILE的DATAFILE SCN

　　如果你有進行RESTORE DATAFILE，則該RESTORE的DATAFILE HEADER SCN一定會小于目前CONTROLFILE的DATAFILE SCN，此時會無法開啟數(shù)據(jù)庫，必須進行media recovery。 重做archive log直到該datafile header的SCN=current scn

　　2） RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;

　　==> DATAFILE HEADER SCN一定會大于CONTROLFILE的DATAFILE SCN

　　如果只是某TABLE被DROP掉，沒有破壞數(shù)據(jù)庫整體數(shù)據(jù)結構，還可以用NCOMPLETE RECOVERY解決 如果是某個TABLESPACE OR DATAFILE被DROP掉，因為檔案結構已經破壞，目前的CONTROL FILE內已經沒有 該DATAFILE的信息，就算你只RESTORE DATAFILE然后進行INCOMPLETE RECOVERY也無法救回被DROP的DATA FILE。

　　只好RESOTRE 之前備份的CONTROL FILE(里頭被DROP DATAFILE Metadata此時還存在)，不過RESTOREC CONTROL FILE后 此時Oracle會發(fā)現(xiàn)CONTROL FILE內的SYSTEM SCN會小于目前的DATAFILE HEADER SCN，也不等于目前儲存于LOG FILE內的SCN， 此時就必須使用RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE到DROP DATAFILE OR DROP TABLESPACE之前的SCN。

　　3.3.2 不完全恢復

　　不完全恢復是指數(shù)據(jù)庫無法恢復到發(fā)生故障那一點的狀態(tài)，而只能恢復到之前一段時間的狀態(tài)，這就以為著承受一定量的數(shù)據(jù)損失。

　　Oracle 運行時包括參數(shù)文件，控制文件，數(shù)據(jù)文件，聯(lián)機日志，那么哪些文件會導致不完全恢復呢？


參數(shù)文件只是一個文本文件，丟失沒有關系�？刂莆募�通常有多個文件相互冗余。 而且在做全庫備份時，控制文件會被自動備份，故所有文件都損壞，也可以通過備份進行恢復，即使沒有備份，也可以通過重建控制文件來恢復，也不會造成數(shù)據(jù)丟失。如果是數(shù)據(jù)文件損壞，只要有備份和備份后的完整的日志文件，也可以完成恢復，不會造成數(shù)據(jù)丟失。

　　聯(lián)機日志比較特殊，通過前面的介紹，我們知道在數(shù)據(jù)庫異常關機的情況下，它可能造成數(shù)據(jù)丟失。

　　我們來看一下聯(lián)機日志損壞的恢復方法：

　　先用SQL 查看一下出問題的聯(lián)機日志是什么狀態(tài)：

　　SQL> Select thread#,group#,status from v$log;

　　1）如果是Inactive 狀態(tài)的聯(lián)機日志，因為它里面的記錄已經同步到數(shù)據(jù)文件，所以只需要把該日志刪掉即可。

　　2）如果是Active/ current 狀態(tài)的連接日志， 因為他們里面有記錄沒有同步到數(shù)據(jù)文件，可以通過如下方式來恢復：

　　（1）關閉所有實例

　�。�2）在受損實例上，啟動到mount狀態(tài)

　�。�3）執(zhí)行alter database open resetlogs

　�。�4）如果在第三步出現(xiàn)錯誤，并其實需要不完全恢復，就執(zhí)行一下： recover database until cancel

　�。�5）實例啟動成功后，啟動其他實例

　�。�6）立即對數(shù)據(jù)庫進行一次全備。 說明：在做了alter database open resetlogs;會把online redelog file清空，數(shù)據(jù)文件丟失.所以這個時候要做一個全備份。resetlogs命令表示一個數(shù)據(jù)庫邏輯生存期的結束和另一個數(shù)據(jù)庫邏輯生存期的開始，每次使用resetlogs命令的時候，SCN不會被重置，不過oracle會重置日志序列號，而且會重置聯(lián)機重做日志內容.這樣做是為了防止不完全恢復后日志序列會發(fā)生沖突（因為現(xiàn)有日志和數(shù)據(jù)文件間有了時間差）。

renxiao2003

謝謝提供。很好。