教你如何成為Oracle 10g OCP - 第十二章 手工管理的備份與恢復

第十二章  手工管理的備份與恢復

備份分為兩種：  物理備份和邏輯備份

物理備份 -- 指對資料檔案，控制檔案，歸檔日誌檔案的備份，是資料塊級別的備份；
邏輯備份 -- 指對資料庫內部的邏輯物件(比如表)進行的備份，主要工具如exp/expdp 等；

12.1  備份

Oracle所有發生的事務都會記錄到聯機日誌檔案中，當例項crash時，SMON程式能夠利用記錄
在聯機日誌檔案中的重做記錄(redo record)進行前滾。

備註： 

前滾(roll forward) : 將已經寫入redo log file 中但是沒有寫入datafile中的提交與未提交
的資料寫入資料檔案 。 屬於例項恢復，一般在資料庫開啟的時候進行。 

回滾(rollback):  在資料庫開啟之後，oracle會查詢redo log file中記錄的commit maker,根
據undo block中的內容將它回滾到一致的狀態。

聯機日誌檔案(online redo log) 及歸檔日誌，歸檔模式相對簡單，這裡不做介紹 。

 

12.1.1 冷備份

冷備份 - 將資料庫正常關閉以後，使用OS命令將所有資料檔案及控制檔案複製到備份介質上。

非歸檔模式的資料庫只能進行冷備份 。

冷備份時，因為是正常關閉資料庫(不是abort), 因此會觸發完全檢查點，從而將記憶體中的
髒資料塊全都寫入資料檔案，因此關閉的資料庫是乾淨的資料庫。因為冷備份時online redo
log保護的髒資料塊都已經寫入了資料檔案中，所以不再需要聯機日誌檔案了。 如果關閉
的時候使用的shutdown abort, 那麼冷備份的時候需要online redo log 檔案。

相關檢視： dba_data_files , v$controlfile 

除了測試環境，我們一般不會將資料庫置為非歸檔模式，冷備份必須關閉資料庫進行，這是
它最大的缺點 。

 

12.1.2  熱備份 

熱備份優點 - 資料庫始終保持可用
熱備份缺點 - 概念複雜，操作步驟多，配置了歸檔，相對非歸檔冷備份來說對效能有一點影響。

如何設定歸檔模式 -

SQL> shutdown immediate
SQL> startup mount 
SQL> alter database archivelog ;
SQL> alter database open ;
SQL> archive log list;   確認是否是自動歸檔模式 

歸檔模式有兩種 ----- 手工方式和自動方式 

手工方式歸檔 -- 當前聯機日誌檔案A寫滿後，切換到另外一個聯機日誌檔案B時，必須手工發出
命令對A進行歸檔： SQL > alter system archive log current ; 
除非測試目的，我們一般不建議手工歸檔。

自動方式歸檔 -- LGWR在將重做記錄寫入current online redo log時，發現寫滿了，於是切換到
下一個新的online redolog, 進行日誌切換，同時觸發歸檔程式(ARCn), 將當前已經寫滿的聯機
日誌檔案進行歸檔，其中ARCn中的n代表可以啟動多個ARCH程式(1~30)，引數log_archive_max_processes
表示啟動多少個歸檔程式，可以動態調整。

alter system switch log file ;
對單例項資料庫或RAC中的當前例項執行強制日誌切換，歸檔當前重做日誌，Oracle9i之前
如果自動歸檔沒有開啟，就不歸檔當前重做日誌檔案 。

alter system archive log current ;
對資料庫中的所有例項執行日誌切換(只歸檔當前日誌)。

alter system archive log all ;
對資料庫中的非當前未歸檔日誌進行歸檔，不負責歸檔current日誌。設一個繁忙的系統中
有日誌6個組，分別是group1~6；當前的日誌組是group5，而歸檔程式正在操作group3的內
容，未寫完；這個時候group4就是未歸檔的非當前日誌。

-------------------------------------------------------- 
在Oracle9i及以前版本，在ARCHIVELOG模式下，LOG_ARCHIVE_START=FALSE時，系統在迴圈到
第一組沒有歸檔的log時，系統會hang住，必須靠DBA手工一個個去歸檔，如果log group
數量多，直接運 ALTER SYSTEM ARCHIVE LOG ALL; 就可以了。

如果 LOG_ARCHIVE_START=TRUE時，一般情況下只要執行：ALTER SYSTEM ARCHIVE LOG CURRENT;
-------------------------------------------------------- 

log_archive_start引數在10g中被廢棄 --

在Oracle10g中，log_archive_start引數已經被廢棄，只要啟動資料庫的歸檔模式，Oracle就會
啟用自動歸檔，避免了10g以前由於使用者疏忽所帶來的一些問題。

 

--- 歸檔日誌檔案路徑

log_archive_dest_1 = 'location=/u01/backup'
location 說明將歸檔日誌檔案放在本地目錄下。

log_archive_dest_2 = 'service=std' 
放在遠端伺服器目錄上，具體放在遠端伺服器哪個目錄下，由遠端伺服器上的standby_archive_dest
來決定，在11g中這個引數被廢棄了 。

log_archive_dest_1 = 'location=/u01/backup/  mandatory reopen=600'  
log_archive_dest_2 = 'location=/u02/backup/  optional'
mandatory表示只有將聯機日誌檔案成功歸檔到/u01/backup/目錄後，該聯機日誌檔案
才能被覆蓋，否則不能被覆蓋。reopen表示一旦不能成功歸檔到指定目錄，則每個600秒
嘗試再次歸檔到該路徑;   optional 表示即使當前聯機日誌檔案沒有成功歸檔到/u02/backup/
下，該聯機日誌檔案也是可以被覆蓋的。

必須成功歸檔的路徑個數相關引數 ---

A. 定義為mandatory的歸檔路徑的個數；
B. 初始化引數log_archive_min_succeed_dest 值, 必須成功歸檔的路徑個數；
C. log_archive_dest_state_1 對應 log_archive_dest_1 , 值enable表示歸檔路徑可用，
   defer表示對應歸檔路徑不可用。

-- Log_archive_format
A. %s - 日誌序列號
B. %S - 固定長度的日誌序列號，不足位數在左邊以0補齊
C. %t - 日誌執行緒號, thread
D. %T - 固定長度的日誌執行緒號，不足位數在左邊以0補齊
E. %a - 啟用ID
F. %d - 資料庫ID
G. %r - resetlogs生成的ID

組合的例子： %t_%s_%r.dbf 

 

12.1.2.2  熱備份資料庫

熱備份過程 --  
SQL> alter tablespace users begin backup ;
複製此表空間下的資料檔案到備份介質上；
SQL> alter tablespace users end backup ;
SQL> alter system switch logfile; 強制歸檔一次current redo.
對每個表空間執行上述過程；
備份所有的歸檔日誌檔案 ；

 

--- 為什麼只有將表空間設定為begin backup模式後才能進行複製呢 ？

Oracle資料塊的大小是作業系統資料塊的整數倍，如果直接透過OS命令複製資料
檔案到備份介質，由於資料庫一直在使用，我們透過OS命令複製資料檔案是以
OS Block為單位進行的，那麼一個Oracle block會被分成好幾次被作業系統複製，
我們可能在複製一個Oracle block中的一些OS Block的時候，該Oracle block因為
使用者操作而被修改了，那麼這個Oracle block中一部分OS Block已經被複製過去了，
而這個Oracle block中的後一半部分被改動過了，該資料塊的狀態已經不一致了，
該Oracle block的備份是不能被使用的(因為block內部版本不一致)，這叫做分離
資料塊(split blocks)的現象。

Oracle判斷某個資料塊是否出現這種分離的現象，是透過比較資料塊頭部和尾部的
版本號是否一致來實現的。只要修改了資料塊，Oracle就會同時更新資料塊頭和尾
的版本號，因此，如果頭尾版本號不一致，說明該資料塊損壞，不能被使用。

發出begin backup以後，第一次修改資料塊中的資料行之前，在online redo log檔案
中記錄整個資料塊的修改前的資料(以重做記錄形式)。在使用熱備份進行恢復時，一旦
發現某個資料塊被分離，則會利用日誌檔案中記錄的資料對整個資料塊進行恢復 。

期間如果有第二次，第三次修改了資料塊 ，只是記錄整個資料塊第一次修改前的
資料到聯機日誌檔案 。

 

--- 為什麼熱備份期間產生了比平時多的歸檔日誌

由於記錄了整個資料塊中所有資料行的重做記錄，而不是隻記錄被修改的資料行的重做記錄.
因此，熱備份中我們會發現產生的歸檔日誌量比平時多，熱備份期間，如果DML操作有很多，
則產生的歸檔日誌會更多。

 

--- 熱備份為什麼要凍結資料檔案頭的SCN及日誌序列號

當發出begin backup以後，Oracle會對被備份的表空間說對應的資料檔案觸發檔案級別的
檢查點，將內容中屬於該表空間的所有dirty block寫入資料檔案。檢查點結束以後，資料
檔案頭部(第1，2號資料塊)記錄的檢查點SCN號和日誌序列號不再變化，直到end backup發出。
儘管熱備會凍結檔案頭部的SCN和日誌序列號，但是資料檔案內容本身還是最新的，使用者對
資料檔案中的資料行做修改時，DBWn仍然會將最新的內容寫入到被備份的表空間中去。

之所有要凍結DATAFILE的檢查點SCN及日誌序列號，是為了將來使用熱備恢復的時候知道從
哪裡開始應用重做記錄，也就是從備份出來的資料檔案頭部記錄的日誌序列號對應的日誌
檔案開始，而在該日誌檔案中，則從資料檔案頭部記錄的檢查點SCN開始向後應用所有的
日誌檔案 。 

熱備份完畢，發出end backup命令以後，這時資料檔案頭部的檢查點SCN號將前推至資料庫
檢查點，同時日誌序列號也將前推至當前最新的日誌序列號。

--- 熱備相關檢視

v$backup 可以檢視哪些表空間正出於熱備狀態
比如有時候我們熱備某個表空間時，資料庫或OS忽然crash, 再次startup庫的時候，發現
報錯，那麼我們需要查詢v$backup 來檢視哪些出於熱備狀態，發出end backup, 然後開啟
即可 。

 

--- 備份控制檔案

如果發生增加，刪除或重命令資料檔案或日誌檔案，那麼我們應該備份控制檔案 。

備份控制檔案的兩種方式：

A. 二進位制方式，一旦控制檔案損壞，可以直接拿來使用。
alter database backup controlfile to '/u01/backup/control.ctl.bak' ;

B. SQL命令的方式在udump下生成一個trace檔案。如果控制檔案丟失，可以
選取這個文字檔案中的create controlfile部分，將DB置為nomount狀態，執行
指令碼重建控制檔案 。
alter database backup controlfile to trace ;

--- 初始化引數及密碼檔案的備份，直接複製即可。

12.2  介質恢復 

介質恢復的過程 --  restore(OS段檔案復原) + recover(將歸檔日誌或聯機日誌
重做記錄apply到還原出來的檔案上) 。 

開啟資料庫時，所有的資料檔案(除了offline及read only的),控制檔案和聯機日誌檔案
必須同步一致，才能開啟資料庫 。 否則必須恢復到一致才能開啟 。

--- 資料庫的一致性

一致性是基於檢查點SCN號(checkpoint SCN)和日誌序列號而言的，透過比較各個檔案的
檔案頭中記錄的檢查點SCN號和日誌序列號是否相同來判斷資料庫是否為一致的。其中主
要的檢查點SCN號都記錄在控制檔案中。

--- 檢查點SCN (控制檔案中)

在控制檔案中記錄了3種主要的檢查點SCN號：
A, 系統檢查點SCN號(system checkpoint SCN) 
B, 資料檔案檢查點SCN號(datafile checkpoint SCN)
C, 結束檢查點SCN號(end checkpoint SCN)

備註： 還有一種檢查點SCN記錄在資料檔案頭部，start SCN (ORACLE將Start SCN號
存放在資料檔案頭中。這個SCN用於檢查資料庫啟動過程是否需要做media recovery).

 

- 系統檢查點SCN
當CKPT啟動時，會將檢查點結束時的SCN號記錄在控制檔案裡，該檢查點是全域性範圍的，
如果發生檔案級別的檢查點，比如表空間begin backup引起檢查點，不會更新系統檢查
點SCN 。系統檢查點SCN可以透過v$database中的checkpoint_change# 查詢到。

- 資料檔案檢查點SCN
當CKPT啟動時，包括全域性範圍及檔案級別的檢查點，全域性範圍比如發生日誌切換，這時
會在控制檔案中記錄每個資料檔案上發生的檢查點SCN . 使用v$datafile可以查詢到每
個資料檔案所對應的檢查點SCN . 

備註： 將datafile設定為正常離線，只讀，或將表空間設定為begin backup時，觸發
檔案級別的檢查點，並將該檢查點更新控制檔案和資料檔案頭部後，就不再變化了。

例子：

SQL> alter tablespace users read only ;

發出後查詢v$database中的checkpoint_change# 為 166025 ，這個是系統
檢查點SCN, 查詢v$datafile 中的 checkpoint_change# ，發現users表空間
對應的檔案的資料檔案檢查點SCN號為 166026 ，而其他表空間對應的資料文
件檢查點SCN 仍然為 166025，因為沒有發生全域性性檢查點，所以控制檔案中
的系統檢查點SCN沒有變化。其他資料檔案沒有發生檔案級別的檢查點，所以
資料檔案檢查點SCN號等於這時的系統檢查點SCN,  沒有增加 。

 

- 結束檢查點SCN  
ORACLE將End SCN號存放在控制檔案中。這個SCN號用於檢查資料庫啟動過程是
否需要做instance recovery.

每個資料檔案都會有一個結束SCN號，在資料庫正常執行中，線上的和可讀可寫
的資料檔案，其終止SCN都為空，而當正常關閉資料庫時或者將資料檔案設定為
begin backup, 正常offline或read only時，都會由於觸發了檢查點程式在控制
檔案中記錄每個資料檔案上的結束SCN號，使用下面的SQL語句查詢每個資料檔案
的SCN號：
SQL> select file#, last_change#  from  v$datafile ;

可以發現其他資料檔案的結束SCN都為空，設定為READ ONLY的有結束SCN號 166026 。

如果關閉資料庫，然後開啟為mount狀態，發現每個檔案都有結束SCN.
然後OPEN資料庫， 發現又回到只有read only的檔案有結束SCN, 其他為空的狀態。

-- 資料檔案頭中的檢查點SCN與控制檔案中記錄的資料檔案檢查點SCN號含義是一樣的。
也就是說，一旦發生全域性範圍以及檔案級別的檢查點時，不僅會將這時的檢查點SCN號
記錄到控制檔案，還會記錄在檢查點作用的資料檔案頭部。

select name, checkpoint_change#  from v$datafile_header ; 

 

 

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

幾種重要的SCN


Commit SCN
當使用者提交commit命令後，系統將當前scn賦給該transaction。這些資訊都反映在redo buffer中，並馬上更新到redo log 檔案裡。


Offline SCN
除了System tablespace以外的任何表空間，當我們執行SQL>alter tablespace … offline normal命令時，就會觸發一個checkpoint，將記憶體中的dirty buffer寫入磁碟檔案中。Checkpoint
完成後，資料檔案頭會更新checkpoint scn和offline normal scn值。其中資料庫檔案頭的checkpoint scn值可透過查詢列x$kccfe.fecps得到。
如果執行SQL>alter tablespace …offline命令時採用temporary或 immediate選項，而不用normal選項時，offline normal scn會被設成0。這樣當資料庫重啟後透過resetlog方式開啟時，
該表空間就無法再改回線上狀態。




Checkpoint SCN
當資料庫記憶體的髒資料塊(dirty blocks)寫到各資料檔案中時，就發生一次checkpoint。資料庫的當前checkpoint scn值存在x$kccdi.discn中。Checkpoint scn在資料庫恢復中起著至關重要
的作用。無論你用何種辦法恢復資料庫，只有當各個資料庫檔案的checkpoint scn都相同時，資料庫才能開啟。雖然引數“_allow_resetlogs_corruption”可以在checkpoint scn不一致時強
制開啟資料庫，但是這樣的資料庫在open後必須馬上作全庫的export，然後重建資料庫並import資料。



Resetlog SCN
資料庫不完全恢復時，在指定時間點後的scn都無法再應用到資料庫中。Resetlog時的scn就被設成當前資料庫scn，redo log也會被重新設定。



Stop SCN
Stop scn記錄在資料檔案頭上。當資料庫處在開啟狀態時，stop scn被設成最大值0xffff.ffffffff。在資料庫正常關閉過程中，stop scn被設定成當前系統的最大scn值。在資料庫開啟過程
中，Oracle會比較各檔案的stop scn和checkpoint scn，如果值不一致，表明資料庫先前沒有正常關閉，需要做恢復。




High and Low SCN
Oracle的Redo log會順序紀錄資料庫的各個變化。一組redo log檔案寫滿後，會自動切換到下一組redo log檔案。則上一組redo log的high scn就是下一組redo log的low scn。
在檢視v$log_history中，sequence#代表redo log的序列號，first_change#表示當前redo log的low scn，列next_change#表示當前redo log的high scn。

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

 

 

補充資料：
-------------------------------------------------------------------- 
以下資料來自於網路： 
與checkpoint相關的SCN號有四個，其中三個存在控制檔案中，一個存放在資料檔案頭中。
具體參考：  http://space.itpub.net/35489/viewspace-674151 
--------------------------------------------------------------------

資料庫的一致性 --

在資料庫啟動過程中，當System Checkpoint SCN、Datafile Checkpoint SCN和
Start SCN號都相同時，資料庫可以正常啟動，不需要做media recovery.三者當
中有一個不同時，則需要做media recovery.如果在啟動的過程中，End SCN號為
NULL，則需要做instance recovery.ORACLE在啟動過程中首先檢查是否需要media recovery，然後再檢查是否需要instance recovery.

當資料由於庫正常關閉時，觸發一個完全檢查點，並用檢查點結束時的SCN號更新幾個資料
檔案的檢查點SCN號(除了offline的和read only的以外)，因此當下次啟動資料庫的時候，
會比較這幾個檢查點SCN號，如果他們相同，說明資料庫是一致的，可正常開啟DB.

如果資料庫發生了非正常關閉, 資料庫還來不及進行一個完全檢查點,整個庫就崩潰了,
這時, 由於來不及更新資料檔案的終止SCN, 每個線上的以及可讀寫的資料檔案的終止
SCN號仍然為空，下次啟動資料庫時，發現這些資料檔案的終止SCN為空，則會由SMON
程式進行例項恢復。當SMON程式完成前滾後，開啟資料庫。

如果我們用備份的檔案覆蓋當前的資料檔案，開啟DB時Oracle會發現記錄在控制檔案
中的資料檔案檢查點SCN號與備份還原出來的資料檔案頭部記錄的檢查點SCN號不一致，
因為控制檔案比較新，備份還原出來的資料檔案比較舊，控制檔案中記錄的檢查點SCN
號要大於還原出來的的資料檔案頭部記錄的檢查點SCN. 這時資料庫不能開啟，會要求
對檢查點SCN比較小的還原的資料檔案進行恢復，應用重做記錄，從而將該資料檔案頭
部的SCN提升到控制檔案中記錄的檢查點SCN號 。

如果我們用舊的備份的控制檔案覆蓋當前的控制檔案，這時控制檔案比較舊，而資料
檔案時當前最新的資料檔案，資料庫會發現控制檔案裡記錄的資料檔案檢查點SCN號
要比資料檔案頭部檢查點SCN號小，也會要求進行恢復 。

在啟動DB時，如果控制檔案中的資料檔案檢查點SCN和資料檔案頭部記錄的檢查點SCN
相同，但是每個線上的可讀寫的資料檔案之間，他們的檢查點SCN不一致，也會要求
進行介質恢復。  

 

補充：
----------------------------------------------------------

SCN號與資料庫啟動 
    在資料庫啟動過程中，當System Checkpoint SCN、Datafile Checkpoint SCN
和Start SCN號都相同時，資料庫可以正常啟動，不需要做media recovery.三者當
中有一個不同時，則需要做media recovery.如果在啟動的過程中，End SCN號為
NULL，則需要做instance recovery.ORACLE在啟動過程中首先檢查是否需要media
recovery，然後再檢查是否需要instance recovery.

SCN號與資料庫關閉
    如果資料庫的正常關閉的話，將會觸發一個checkpoint，同時將資料檔案的END SCN
號設定為相應資料檔案的Start SCN號。  當資料庫啟動時，發現它們是一致的，則不需
要做instance recovery。在資料庫正常啟動後，ORACLE會將END SCN號設定為NULL.如果
資料庫異常關閉的話，則END SCN號將為NULL.

為什麼需要System checkpoint SCN號與Datafile Checkpoint SCN號
    為什麼ORACLE會在控制檔案中記錄System checkpoint SCN號的同時，還需要為每
個資料檔案記錄Datafile Checkpoint SCN號？
  原因有二：
    1.對只讀表空間，其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN
號均相同。這三個SCN在表空間處於只讀期間都將被凍結。
    2.如果控制檔案不是當前的控制檔案，則System checkpoint會小於Start SCN或
END SCN號。記錄這些SCN號，可以區分控制檔案是否是當前的控制檔案。

Recovery database using backup controlfile
    當有一個Start SCN號超過了System Checkpoit SCN號時，則說明控制檔案不是當
前的控制檔案，因此在做recovery時需要採用using backup controlfile。這是為什麼
需要記錄System  Checkpoint SCN的原因之一。這裡需要一提的是，當重建控制檔案的
時候，System Checkpoint SCN為0，Datafile Checkpoint SCN的資料來自於Start SCN。
根據上述的描述，此時需要採用using backup controlfile做recovery.

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

 

 

12.2.1  完全恢復

完全恢復 -- 表示將資料庫恢復到備份允許的最新狀態，分為非歸檔及歸檔模式下的
完全恢復 。

非歸檔完全恢復 -- 及時只是丟失一個資料檔案，也必須還原所有的資料檔案，
還原或不還原聯機日誌檔案都可以(看是否有備份)，還原時用的備份必須是同
一個時間點上做的備份 。

A. 在備份的時候，同時備份了聯機日誌檔案
這個恢復過程很簡單，只需要關閉DB, 透過OS命令複製最近的一次備份到原來目錄即可。

B. 在備份的時候沒有備份聯機日誌檔案
按照上面的步驟複製資料檔案及控制檔案到原來目錄，啟動資料庫時會報錯找不到聯機
日誌檔案或不匹配等類似資訊，這時候我們可以：

SQL> recover database until cancel using backup controlfile ;  

提示輸入日誌檔案的時候，直接輸入cancel ; 然後
SQL> alter database open resetlogs ;

 

-------------------------------------------------------------- 
備註：

在普通的recover database 或者 recover tablespace, recover datafile時
(即不加using backup controlfile)，Oracle會以當前controlfile所紀錄的SCN為準，
利用archive log和 redo log的redo entry, 把相關的datafile的 block恢復到“當
前controlfile所紀錄的SCN” .

而某些情況下，Oracle需要把資料恢復到比當前controlfile(一般當前controlfile是
以前備份的或著透過trace檔案中的create controlfile新建的) 所紀錄的SCN靠後的
位置， 這時候，就需要用using backup controlfile.  恢復就不會受“當前
controlfile所紀錄的SCN”的限制。這時候的限制就來自於你的語句(until time ,
until scn)，或者可用的archive log (until cancel) 。

create controlfile resetlogs/noresetlogs
1）．用noresetlogs重建控制檔案時，控制檔案中datafile checkpoint來自online
redo logs中的Current log頭 ( 參考前面說到的，redo log 中也有對應的SCN ;      redo損壞的話，就不能使用noresetlogs)  
2）．用resetlogs重建控制檔案時，控制檔案中datafile checkpoint來自各資料檔案頭。

以下條件需要使用using backup controlfile
1）、使用備份控制檔案
2）、重建resetlogs控制檔案,如果重建立noresetlogs不必要使用using backup
controlfile

以下條件需要使用resetlog (使用resetlogs開啟DB後務必完整備份一次資料庫)
1）在不完全恢復（介質恢復）
2）使用備份控制檔案 

具體參考：
http://space.itpub.net/35489/viewspace-674270  
--------------------------------------------------------------   

 

12.2.1.2  歸檔模式下的完全恢復 

1. 歸檔模式下，如果控制檔案和聯機日誌檔案都沒有損壞，而資料檔案損壞，那麼只要
存在備份以及自從備份以來所有的歸檔日誌檔案，那麼可以將DB恢復到發生介質損壞的
那個時間點上 。

2. 如果所有控制檔案損壞或者整個聯機日誌檔案丟失，或自從最新的備份以來丟失了某
個歸檔日誌檔案，則不能進行完全恢復，只能進行不完全恢復。

 

--- 歸檔模式下完全恢復的三個級別：
A. 資料庫級別； B. 資料檔案級別； C. 表空間級別

恢復整個資料庫需要將資料庫啟動到mount階段，如果恢復某個資料檔案或者恢復某個表
空間，則可以在資料庫開啟狀態下進行 (系統表空間和undo表空間除外)。

--- 恢復過程
當發出recover命令時，Oracle從所有被還原的資料檔案頭中選擇一個最小的檢查點SCN號
及日誌序列號，從該日誌序列號指定的日誌檔案開始，向後依次開始應用所有的重做記錄。
應用重做記錄會一致持續，直到每個資料檔案頭部的檢查點SCN號達到控制檔案中所記錄的
資料檔案檢查點SCN為止。 

Oracle在恢復一個資料檔案的時候，必須以獨佔的方式鎖定被恢復的資料檔案，如果不能
鎖定，則報出錯誤。

--- 相關的檢視
當資料檔案損壞或丟失需要介質恢復時，我們可以先透過查詢v$recover_file來確定哪些
檔案需要進行介質恢復，然後可以查詢v$recover_log 顯示需要完全恢復受損的資料檔案，
需要應用哪些日誌檔案 。

 

--- 恢復方式
確定了要恢復的資料檔案以後，我們可以確定使用那種方式進行恢復。

A. recover database :  資料庫關閉的時候使用(mount階段)，若系統表空間或undo表
空間損壞，或者所有資料檔案損壞，只能使用這種方式。

B. recover tablespace + 表空間名或編號 :  可以在資料庫open的狀態下進行，在恢復
表空間之前，必須將要恢復的表空間離線(offline)。在非系統表空間及非undo表空間損壞
時，推薦使用該方式。 注意，這裡的資料庫open指的是資料庫一直是open的，雖然期間
有資料檔案出問題需要recover .  

C. recover datafile + 資料檔名或編號 :  資料庫open或非open時(mount階段)都能
使用，恢復之前，必須將要恢復的資料檔案離線。 資料庫open時，不能用於系統表空間和
undo表空間的資料檔案。 

--- 使用歸檔進行恢復

讓Oracle自動應用所有的歸檔日誌，可以用以下方式：
A. SQL> set autorecovery on ;
   SQL> recover datafile 4 ;
B. recover datafile 4 ;  輸入auto .
C. recover automatic datafile 4 ;

 

--- 完全恢復例子 ：

1. 模擬user表空間損壞 (資料庫為open狀態)
SQL> create table hr.tab1 tablespace users as select * from user_objects;
SQL> !rm -rf $ORACLE_BASE/oradata/ora10g/user01.dbf
SQL> alter system flush buffer_cache ;  清空buffer cache;
SQL> select count(*) from hr.tab1 ;  報錯

我們開始恢復users表空間 (這時資料庫還是open狀態)。

A. alter tablespace users offline immeidate ;
B. 還原user01.dbf的備份 ;
C. 查詢v$recover_file 及 v$recover_log 檢視; 
D. recover automatic tablespace users ;

2. 資料庫當前為關閉狀態，系統表空間和undo表空間損壞 。

A. 啟動DB到mount階段： SQL>startup mount ;
B. 還原系統表空間的資料檔案或者受損的資料檔案;
C. 恢復資料庫 SQL> recover automatic database ;
   或者只恢復受損的系統表空間即可
   SQL > recover automatic datafile 1 ;     

D. 開啟資料庫 SQL> alter database open ;  

3. 資料庫為關閉狀態，系統表空間及UNDO都沒有損壞，其他表空間損壞

A. 啟動資料庫到mount狀態，SQL>startup mount;
B. 設定損壞的資料檔案為離線狀態
   SQL>alter database datafile 4 offline ;
C. 從備份中還原4號檔案；  (因為受損的datafile已經離線，所以如果這時使用者需要使用此資料庫也是可以開啟的) 
D. SQL>recover automatic adtafile 4 ; (這時資料庫可能是mount或open狀態)
E. 恢復完成後將4號檔案ONLINE
   SQL> alter database datafile 4 online ;

4.    資料檔案沒有備份，恰好丟失，但是有這個檔案建立以來所有的歸檔
A. 假設users表空間的users01.dbf丟失，將丟失的資料檔案設定為OFFLINE
   SQL> alter database datafile 'xxxx' offline ;
B .因為沒有user01.dbf的備份，我們需要重建一個內容為空的user01.dbf.
   SQL>alter database create datafile   'xxxx';
   我們可以查詢v$datafile看到空的資料檔案的scn是控制檔案中記錄的建立
   該資料檔案時候的SCN.
C. 恢復資料檔案 recover automatic datafile 6 ; 恢復完畢後可以檢視到
   資料檔案頭部的檢查點SCN與控制檔案記錄的檢查點SCN一致，可以檢視
   檢視 v$datafile_header及v$datafile; 
D. alter database datafile 6 online ;

 

12.2.2  不完全恢復

如果需要將資料庫恢復到歷史上的某個時間點，或者由於丟失了聯機日誌檔案或歸檔日誌檔案，
或者使用了以前備份的控制檔案進行恢復時，則進行的恢復叫做不完全恢復，恢復到歷史時間
點後的資料變化將會全部丟失，不完全恢復比較危險，只有在必要的情況下才進行不完全恢復。

--- 通常出現以下情況才需要進行不完全恢復。

A. 進行完全恢復的時候如果丟失一個或多個歸檔，這時候只能將資料庫做不完全恢復。
B. 丟失了整個聯機日誌組，而該聯機日誌檔案組還沒有完成歸檔。
C. 使用者誤刪除了表中資料，表或某個重要使用者，可以透過備份進行不完全恢復到誤操作之前
   的時間點。
D. 當前控制檔案全部丟失，並使用了備份的控制檔案進行恢復,這時進行的是不完全恢復，
   不過如果所有歸檔及聯機日誌檔案都在，仍然可以恢復所有的資料。

--- 進行不完全恢復的兩個前提
A. 具有所有資料檔案的備份，並且該備份是在要恢復到的時間點之前做的。
B. 具有從備份時間點開始，到要恢復的時間點之間的所有歸檔日誌檔案。

--- 存在以下三種型別的不完全恢復
A. 基於時間點的不完全恢復：
SQL> recover database until time  'yyyy-mm-dd hh24:mi:ss' ；
SQL> recover database until time  '2010-09-10 14:29;16' ；
SQL> recover database automatic until time '2010-09-10 14:29;16' ；
SQL> alter database open resetlogs  ；

B. 基於CANCEL的不完全恢復，恢復到我們輸入cancel為止。這種方式通常用於丟失聯機日誌
檔案或歸檔日誌檔案。
SQL> recover database until cancel;

C. 基於SCN的不完全恢復，和基於時間的恢復比較類似，如果我們能確定恢復到SCN,否則建議
使用基於時間點的恢復。
SQL> recover database until cancel scn ;

不完全恢復容易出現人為錯誤，所以在進行不完全恢復的之前最好關閉資料庫，並進行冷備份。
如果沒有條件冷備份，至少應該歸檔當前的聯機日誌檔案及備份當前的控制檔案：
SQL> alter system archive log current ;
SQL> alter database backup controlfile to trace (或某路徑) ;

在不完全恢復之前，應該檢查alter log檔案，可能從中找到誤操作的一些時間和SCN方面的資訊。

 

--- 進行不完全恢復的步驟。