編輯手記：備份重于一切，我們必需知道,系統(tǒng)總是要崩潰的，沒有有效的備份只是等哪一天死！今天你備份了嗎？我們一起來回顧Oracle的物理備份，本文摘自《循序漸進(jìn)Oracle》
邏輯備份：Oracle的邏輯備份與恢復(fù)
正文：
物理備份是指針對Oracle的文件進(jìn)行的備份，這與邏輯備份針對數(shù)據(jù)的備份不同。在物理備份中，數(shù)據(jù)庫使用的重要文件都需要進(jìn)行針對性的備份，這些文件包括數(shù)據(jù)文件（DATA FILE）、控制文件（CONTROL FILE）、聯(lián)機(jī)日志文件（REDO LOG）、歸檔日志文件（ARCHIVE LOG）和參數(shù)文件及口令文件等（可選）。
需要注意的是，臨時(shí)文件因?yàn)椴淮鎯?chǔ)永久數(shù)據(jù)，所以可以不必備份，在恢復(fù)后可以重新創(chuàng)建臨時(shí)表空間的臨時(shí)文件。根據(jù)備份方式的不同，物理備份又可以分為冷備份和熱備份。
冷備份
冷備份是指關(guān)閉數(shù)據(jù)庫的備份，又稱脫機(jī)備份或一致性備份，在冷備份開始前數(shù)據(jù)庫必須徹底關(guān)閉。關(guān)閉操作必須用帶有normal、transaction、immediate選項(xiàng)的shutdown來執(zhí)行。
冷備份通常適用于業(yè)務(wù)具有階段性的企業(yè)，比如白天運(yùn)行、夜間可以停機(jī)維護(hù)的企業(yè)，冷備份操作簡單，但是需要關(guān)閉數(shù)據(jù)庫，對于需要24×7提供服務(wù)的企業(yè)是不適用的。
在進(jìn)行冷備份之前通常需要做一些準(zhǔn)備工作，例如，確定數(shù)據(jù)文件的名稱及路徑、確定日志文件的名稱及路徑等。很多數(shù)據(jù)庫出于空間或負(fù)載分擔(dān)的考慮，會(huì)將文件分散存儲(chǔ)到不同的硬盤或分區(qū)，所以在備份時(shí)一定要注意包含所有的需要備份文件。我曾經(jīng)見過有的公司在恢復(fù)時(shí)才發(fā)現(xiàn)冷備份漏掉了部分文件，這種錯(cuò)誤在工作中是應(yīng)該避免的。
以下幾個(gè)查詢在備份之前應(yīng)當(dāng)執(zhí)行，以確認(rèn)數(shù)據(jù)庫文件及存儲(chǔ)路徑：
SQL> select name from v$datafile;
NAME
-----------------------------------------------------
/opt/oracle/oradata/eygle/system01.dbf
/opt/oracle/oradata/eygle/undotbs01.dbf
/opt/oracle/oradata/eygle/sysaux01.dbf
/data1/oradata/systemfile/eygle01.dbf
SQL> select member from v$logfile;
MEMBER
---------------------------------------------------
/opt/oracle/oradata/eygle/redo01.log
/opt/oracle/oradata/eygle/redo02.log
/opt/oracle/oradata/eygle/redo03.log
SQL> select name from v$controlfile;
NAME
---------------------------------------------------
/opt/oracle/oradata/eygle/control01.ctl
/opt/oracle/oradata/eygle/control02.ctl
/opt/oracle/oradata/eygle/control03.ctl
冷備份的通常步驟是：
正常關(guān)閉數(shù)據(jù)庫；
備份所有重要的文件到備份目錄；
完成備份后啟動(dòng)數(shù)據(jù)庫。
為了恢復(fù)方便，冷備份應(yīng)該包含所有的數(shù)據(jù)文件、控制文件和日志文件，這樣當(dāng)需要采用冷備份進(jìn)行恢復(fù)時(shí)，只需要將所有文件恢復(fù)到原有位置，就可以啟動(dòng)數(shù)據(jù)庫了。
熱備份
由于冷備份需要關(guān)閉數(shù)據(jù)庫，所以已經(jīng)很少有企業(yè)能夠采用這種方式進(jìn)行備份了，當(dāng)數(shù)據(jù)庫運(yùn)行在歸檔模式下時(shí)，Oracle允許用戶對數(shù)據(jù)庫進(jìn)行聯(lián)機(jī)熱備份。
熱備份又可以簡單的分為兩種：用戶管理的熱備份（user-managed backup and recovery,）和Oracle管理的熱備份（Recovery Manager-RMAN）。
用戶管理的熱備份是指用戶通過將表空間置于熱備份模式下，然后通過操作系統(tǒng)工具對文件進(jìn)行復(fù)制備份，備份完成后再結(jié)束表空間的備份模式。
Oracle管理的熱備份通常指通過RMAN對數(shù)據(jù)庫進(jìn)行聯(lián)機(jī)熱備份，RMAN執(zhí)行的熱備份不需要將表空間置于熱備模式，從而可以減少對于數(shù)據(jù)庫的影響獲得性能提升。另外RMAN的備份信息可以通過控制文件或者額外的目錄數(shù)據(jù)庫進(jìn)行管理，功能強(qiáng)大但是相對復(fù)雜。
下面分別來介紹一下用戶管理的備份和RMAN
用戶管理的熱備份通常包含以下幾個(gè)步驟：
（1）在備份之前需要顯示的發(fā)出Begin Backup的命令；
（2）在操作系統(tǒng)拷貝備份文件（包括數(shù)據(jù)文件、控制文件等）；
（3）發(fā)出end backup命令通知數(shù)據(jù)庫完成備份；
（4）備份歸檔日志文件。
常見的備份過程如下，這里以一個(gè)表空間的備份為例：
alter tablespace system begin backup;
host copy E:\ORACLE\ORADATA\EYGLE\SYSTEM01.DBFe:\oracle\orabak\SYSTEM01.DBF
alter tablespace system end backup;
當(dāng)備份被激活時(shí)，可以通過v$backup視圖來檢查表空間的備份情況：
FILE# STATUS CHANGE# TIME
---------- ------------------ -------------------
1 NOT ACTIVE 0
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 0
SQL> alter tablespace system begin backup;
Tablespace altered.
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
----- ------------------ -----------------------------
1 ACTIVE 1.8995E+102007-02-12 15:54:52
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 0
需要注意的是，當(dāng)表空間置于熱備模式下，表空間數(shù)據(jù)文件頭的檢查點(diǎn)會(huì)被凍結(jié)，當(dāng)熱備份完成，發(fā)出end backup命令后，表空間數(shù)據(jù)文件檢查點(diǎn)被重新同步，恢復(fù)更新：
SQL> alter tablespace system end backup;
Tablespace altered.
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
-------- ------------------ -----------------------------
1 NOT ACTIVE 1.8995E+102007-02-12 15:54:52
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 0
備份的起止時(shí)間會(huì)在警告日志文件中記錄：
Mon Feb 12 15:54:52 2007
alter tablespace system begin backup
Mon Feb 12 15:54:52 2007
Completed: alter tablespace system beginbackup
Mon Feb 12 16:13:00 2007
alter tablespace system end backup
Mon Feb 12 16:13:00 2007
Completed: alter tablespace system end backup
這里需要提醒的是，如果遺忘了end backup命令將會(huì)導(dǎo)致數(shù)據(jù)庫問題，所以使用這種方式備份時(shí)需要確認(rèn)備份正確完成。
2、額外Redo的生成
在使用Begin Backup開始備份時(shí)，數(shù)據(jù)庫會(huì)產(chǎn)生了比平常更多的日志，也就會(huì)生成更多的歸檔。這是因?yàn)樵跓醾浞萜陂g，Oracle為了解決SPLIT BLOCK的問題，需要在日志文件中記錄修改的行所在的數(shù)據(jù)塊的前鏡像（image），而不僅僅是修改信息。
為了理解這段話，還需要簡單介紹一下SPLIT BLOCK的概念。
我們知道，Oracle的數(shù)據(jù)塊是由多個(gè)操作系統(tǒng)塊組成。通常UNIX文件系統(tǒng)使用512bytes的數(shù)據(jù)塊，而Oracle使用8kB的db_block_size。當(dāng)熱備份數(shù)據(jù)文件的時(shí)候，使用文件系統(tǒng)的命令工具（通常是cp工具）拷貝文件，并且使用文件系統(tǒng)的blocksize讀取數(shù)據(jù)文件。
在這種情況下，可能出現(xiàn)如下狀況：當(dāng)拷貝數(shù)據(jù)文件的同時(shí)，數(shù)據(jù)庫正好向數(shù)據(jù)文件寫數(shù)據(jù)。這就使得拷貝的文件中包含這樣的database block，它的一部分OS block來自于數(shù)據(jù)庫向數(shù)據(jù)文件（這個(gè)db block）寫操作之前，另一部分來自于寫操作之后。對于數(shù)據(jù)庫來說，這個(gè)databaseblock本身并不一致，而是一個(gè)分裂塊（SPLIT BLOCK）。這樣的分裂塊在恢復(fù)時(shí)并不可用（會(huì)提示corrupted block）。
所以，在熱備狀態(tài)下，對于變更的數(shù)據(jù)，Oracle需要在日志中記錄整個(gè)變化的數(shù)據(jù)塊的前鏡像。這樣如果在恢復(fù)的過程中，數(shù)據(jù)文件中出現(xiàn)分裂塊，Oracle就可以通過日志文件中的數(shù)據(jù)塊的前鏡像覆蓋備份，以完成恢復(fù)。
來看一下測試，首先通過SYS用戶連接數(shù)據(jù)庫，確認(rèn)SCOTT用戶連接信息及日志信息：
創(chuàng)建一個(gè)視圖用于簡化查詢：
CREATE OR REPLACEVIEW redo_size
AS
SELECT VALUE
FROM v$mystat, v$statname
WHERE v$mystat.statistic# =v$statname.statistic#
AND v$statname.NAME = 'redo size';
然后看一下正常情況下的日志生成：
SQL> select *from redo_size;
VALUE
----------
11972
SQL> update empset sal=10 where empno=7788;
1 row updated.
SQL> commit;
Commit complete.
SQL> select *from redo_size;
VALUE
----------
12484
SQL> select 12484-11972 from dual;
12484-11972
-----------
512
正常的更新操作，大約生成了512 byte的日志。然后用SYS用戶，將EMP表所在的SYSTEM表空間置于熱備份模式：
SQL> altertablespace system begin backup;
Tablespace altered.
使用SCOTT用戶進(jìn)行同樣操作：
SQL> select *from redo_size;
VALUE
----------
8788
SQL> update empset sal=10 where empno=7788;
1 row updated.
SQL> commit;
Commit complete.
SQL> select *from redo_size;
VALUE
----------
17516
SQL> select 17516- 8788 from dual;
17516-8788
----------
8728
注意到這一次，生成了8728 byte的重做，這個(gè)日志量較上次正常模式下大約多出了一個(gè)Block的數(shù)量。然后用SYS用戶轉(zhuǎn)儲(chǔ)日志文件，看一下多出來的日志到底是什么內(nèi)容：
SQL> @gettrcname
TRACE_FILE_NAME
----------------------------------------------------------------------------
/opt/oracle9/admin/testora9/udump/testora9_ora_4692.trc
SQL> ALTER SYSTEMDUMP LOGFILE '/opt/oracle9/oradata/testora9/redo01.log';
System altered.
檢查相關(guān)信息，注意到較常規(guī)狀態(tài)下，增加了“Log block image redo entry”部分，這一部分就是在熱備份時(shí)產(chǎn)生的額外日志信息：
REDO RECORD -Thread:1 RBA: 0x000085.00000020.0010 LEN: 0x2018 VLD: 0x01
SCN: 0x0000.0f8b260c SUBSCN: 103/19/2006 20:24:14
CHANGE #1 TYP:3 CLS:1 AFN:1 DBA:0x0040a482SCN:0x0000.0f8b2471SEQ: 1 OP:18.1
Log block image redo entry
Dump of memory from0x0000000103DB7020 to 0x0000000103DB9008
103DB7020 01080015 000070F3 0F8B2470 00004000 [......p...$p..@.]
103DB8FE0 C11F2C00 0803C24A4605534D 49544805 [..,....JF.SMITH.]
103DB8FF0 434C4552 4B03C250 030777B4 0C110101 [CLERK..P..w.....]
103DB9000 0102C209 FF02C115 [........]
Dump of memory from0x0000000103DB9008 to 0x0000000103DB9009
103DB9000 06401F3A [.@.:]
REDO RECORD -Thread:1 RBA: 0x000085.00000030.0128 LEN: 0x01b0 VLD: 0x01
SCN: 0x0000.0f8b260c SUBSCN: 103/19/2006 20:24:14
CHANGE #1 TYP:0CLS:33 AFN:2 DBA:0x00800089 SCN:0x0000.0f8b25c9 SEQ: 1 OP:5.2
...
KDO Op code: URP rowdependencies Disabled
xtype: XA bdba: 0x0040a482 hdba: 0x0040a481
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 7(0x7)flag: 0x2c lock: 1ckix: 0
ncol: 8 nnew: 1 size:0
col 5: [ 2] c1 0b
CHANGE #4 MEDIARECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
session number = 12
serial number = 28
transaction name =
在Oracle數(shù)據(jù)庫內(nèi)部，存在一個(gè)隱含參數(shù)控制這個(gè)行為：
這個(gè)參數(shù)缺省值為TRUE，設(shè)置在熱備份期間允許在redo中記錄數(shù)據(jù)塊信息，如果數(shù)據(jù)庫塊大小等于操作系統(tǒng)塊大小，則可以設(shè)置該參數(shù)為False，減少熱備期間數(shù)據(jù)庫的負(fù)擔(dān)（這種情況極為少見）。
分裂塊產(chǎn)生的根本原因在于備份過程中引入了操作系統(tǒng)工具（如cp工具等），操作系統(tǒng)工具無法保證Oracle數(shù)據(jù)塊的一致性。如果使用RMAN備份，由于Rman可以通過反復(fù)讀取獲得一致的Blok，從而可以避免SPLIT Block的生成，所以不會(huì)產(chǎn)生額外的REDO。所以建議在備份時(shí)（特別是繁忙的數(shù)據(jù)庫），應(yīng)該盡量采用RMAN備份。
3、定制自適應(yīng)的熱備份腳本
由于數(shù)據(jù)庫經(jīng)常處于變化之中，如表空間文件的增減、新表空間的創(chuàng)建等，所以熱備份的腳本不能一成不變，如果想讓備份充分的自動(dòng)化，必須定制自適應(yīng)的備份腳本。以下是在生產(chǎn)庫中經(jīng)過實(shí)踐的腳本范例（來自UNIX平臺(tái)）供大家參考（為了簡潔，省略了腳本中部分環(huán)境變量設(shè)置等內(nèi)容，詳細(xì)腳本可以從本書代碼包中獲得）。
首先看看crontab中的定義：
$ crontab -l
30 2 * * 0-6/opt/oracle/tools/hotbackup/startbak.sh
整個(gè)備份是通過一個(gè)叫做startbak.sh的腳本啟動(dòng)的，這個(gè)腳本的主要內(nèi)容如下：
……
week=`date+"%w"`
today=`date+"%m%d"`
ps -ef|grepdbw0_$ORACLE_SID |grep -v grep >>/dev/null
if [ $? -eq 0 ];then
if [ $week = "1" ] ; then
$SH_HOME/genbaksql.sh
else
$SH_HOME/dobakarch.sh
fi
fi
腳本根據(jù)時(shí)間進(jìn)行判斷，如果是周一則執(zhí)行全備份，否則執(zhí)行歸檔日志備份，全備份由腳本genbaksql.sh調(diào)用并執(zhí)行，這個(gè)腳本就是根據(jù)數(shù)據(jù)庫信息自動(dòng)生成自適應(yīng)備份腳本的過程，shell腳本包含一系列的SQL*Plus執(zhí)行SQL，執(zhí)行過程通過spool的方式生成另外一個(gè)文件：
……
SQLPLUS -S "/as sysdba" >/dev/null <<EOF
……
SPOOL$SH_HOME/dobackup.sql
genbaksql.sh這個(gè)腳本的主體部分包含如下語句：
SELECT 'PROMPT Begin Backup Tablespace '
|| tablespace_name|| '.'|| file_name||CHR (10)
|| 'alter tablespace ' || tablespace_name|| ' begin backup;'|| CHR(10)
|| '! cp '|| file_name|| '$BACKUP_FILE'|| CHR (10)
|| 'alter tablespace '||tablespace_name|| ' end backup;'|| CHR (10)
|| '! compress '|| '$BACKUP_FILE'||'/*.dbf'|| CHR (10)
|| 'PROMPT Successed End Backup ThisFile . ;'|| CHR (10)
|| 'select CHR(10) from dual;'|| CHR (10)
FROM dba_data_files
WHERE status = 'AVAILABLE';
這個(gè)SQL執(zhí)行之后，會(huì)根據(jù)數(shù)據(jù)庫當(dāng)前的情況生成備份腳本，生成的內(nèi)容類似：
PROMPT Begin BackupTablespace SYSTEM./opt/oracle/oradata/eygle/system01.dbf
alter tablespaceSYSTEM begin backup;
! cp/opt/oracle/oradata/eygle/system01.dbf $BACKUP_FILE
alter tablespaceSYSTEM end backup;
! compress $BACKUP_FILE/*.dbf
PROMPT Successed EndBackup This File . ;
select CHR(10) from dual;
其中壓縮步驟是為了節(jié)省空間，不同環(huán)境可以根據(jù)情況來修改。genbaksql.sh的最后部分通過調(diào)用另外一個(gè)編譯好的shell腳本來調(diào)用以上動(dòng)態(tài)生成的dobackup.sql腳本，執(zhí)行備份：
chmod u+x$SH_HOME/dobackup.sh
$SH_HOME/dobackup.sh
這個(gè)dobackup.sh腳本主要用來執(zhí)行備份，并最終對所有備份文件進(jìn)行打包（還可以加入簡單的過期備份刪除功能），這個(gè)腳本的主要內(nèi)容如下（最后一部分是用來備份歸檔日志的）：
date
echo"--------------------------------------------------------------"
sqlplus "/ assysdba" @$SH_HOME/dobackup.sql
date
$TAR_COMMAND cvf$BACKUP_FILE/hotback`date +"%Y%m%d"`.tar `find $BACKUP_FILE -name"*.Z"`
$RM_COMMAND$BACKUP_FILE/*.Z
find $BACKUP_FILE-name "*.tar" -mtime +10 -exec rm {} \;
cat$SH_HOME/dobackup.log |$MAIL_COMMAND -s "HOT BACKUP FROM $LOCAL" $DBA
echo"-------------------------------------------------"
echo "Beginbackup today archive log files....."
$SH_HOME/dobakarch.sh
echo "Successedin backup archive files"
echo"--------------------------------------------------"
備份歸檔日志的腳本dobakarch.sh是一個(gè)簡單的通用腳本，除了全備份時(shí)調(diào)用，日常也可以在startbak.sh腳本中調(diào)用，其主要內(nèi)容如下：
$SH_HOME/bakarch.sh> $SH_HOME/dobakarch.log
最終的歸檔備份是通過bakarch.sh完成的：
date
echo"-------------------------------------------------"
echo "Beginbackup today archive log files....."
$MV_COMMAND `find$RAEL_ARCH -name "*.arc"` $BACK_ARCH
$TAR_COMMAND cvf$BACK_ARCH/arch$DATE.tar `find $BACK_ARCH -name "*.arc"`
$COMPRESS_COMMAND$BACK_ARCH/arch$DATE.tar
if [ $? ="0" ]; then
$RM_COMMAND$BACK_ARCH/*.arc
fi
find $BACK_ARCH -name"*.tar.Z" -mtime +10 -exec rm {} \;
if [ $? ="0" ]; then
echo "Successed in backup archivefiles"
else
echo "File not find!"
fi
echo"-------------------------------------------------"
這樣就完成了這個(gè)自定制備份腳本。
在Oracle 10g中，Oracle新增命令用以簡化用戶管理的備份，現(xiàn)在可以通過alter databasebegin/end backup來進(jìn)行數(shù)據(jù)庫備份模式的切換，在Oracle 10g之前，需要對每個(gè)表空間逐一進(jìn)行熱備設(shè)置：
SQL> alter session setnls_date_format='yyyy-mm-dd hh24:mi:ss';
Session altered.
SQL> alterdatabase begin backup;
Database altered.
當(dāng)執(zhí)行了alter database begin backup之后，所有表空間一次被置于熱備狀態(tài)，可以通過并行方式對數(shù)據(jù)庫進(jìn)行備份：
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
------ --------------- -----------------------------
1 ACTIVE 8.9255E+12 2010-12-22 16:26:18
2 ACTIVE 8.9255E+122010-12-22 16:26:18
3 ACTIVE 8.9255E+122010-12-22 16:26:18
4 ACTIVE 8.9255E+122010-12-22 16:26:18
5 ACTIVE 8.9255E+122010-12-22 16:26:18
6 ACTIVE 8.9255E+122010-12-22 16:26:18
在執(zhí)行alter databaseend backup，所有表空間將一次性停止熱備：
這是Oracle 10g對于用戶管理熱備的一個(gè)增強(qiáng)。
當(dāng)進(jìn)行了完善的備份之后，接下來的工作就是等候故障出現(xiàn)時(shí)一展身手了（當(dāng)然能夠不出故障是更理想的）。以下通過實(shí)例來說明對于用戶管理的備份進(jìn)行完全恢復(fù)。
完全恢復(fù)的前提是有一個(gè)全備份，為了驗(yàn)證恢復(fù)情況，執(zhí)行如下一系列的數(shù)據(jù)庫操作：
SQL> connect eygle/eygle
SQL> create table eygle as select * fromdba_users;
SQL> select count(*) from eygle;
COUNT(*)
----------
8
SQL> delete from eygle where rownum <5;
SQL> commit;
SQL> alter system switch logfile;
SQL> insert into eygle select * fromdba_users;
SQL> commit;
SQL> select count(*) from eygle;
COUNT(*)
----------
12
SQL> alter system switch logfile;
System altered.
假定此后發(fā)生數(shù)據(jù)庫故障，所有數(shù)據(jù)文件丟失，但是還有當(dāng)前的控制文件和日志文件。
注意：如果當(dāng)前的日志文件丟失，那么數(shù)據(jù)庫只能進(jìn)行不完全恢復(fù)，因?yàn)楫?dāng)前日志中包含的Redo信息對應(yīng)的數(shù)據(jù)修改可能尚未寫入到數(shù)據(jù)文件，丟失當(dāng)前日志文件意味著數(shù)據(jù)庫將會(huì)丟失提交成功的數(shù)據(jù)，恢復(fù)的最大限度只能是進(jìn)行不完全恢復(fù)，恢復(fù)完成后將需要通過Resetlogs打開數(shù)據(jù)庫；如果當(dāng)前控制文件丟失，那么只能通過備份的控制文件或重建控制文件來進(jìn)行恢復(fù)。
但是如果擁有控制文件和日志文件，那么接下來可以進(jìn)行完全恢復(fù)，首先Restore數(shù)據(jù)文件到原有目錄：
[oracle@jumper oradata]$ cp eyglebak/*.dbfeygle
此時(shí)如果嘗試啟動(dòng)數(shù)據(jù)庫，Oracle就會(huì)提示需要介質(zhì)恢復(fù)，這是根據(jù)控制文件及數(shù)據(jù)文件頭的信息進(jìn)行判斷的：
SQL> startup
ORACLE instance started.
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1:'/opt/oracle/oradata/eygle/system01.dbf'
正常情況下，可以先啟動(dòng)數(shù)據(jù)庫到Mount狀態(tài)，然后開始恢復(fù)：
SQL> startup mount;
ORACLE instance started.
Database mounted.
因?yàn)槲覀儞碛凶钚碌目刂莆募约八械臍w檔及在線日志文件，所以可以簡單地通過一條命令執(zhí)行恢復(fù)，在恢復(fù)過程中，Oracle會(huì)提示歸檔文件，可以輸入Auto讓Oracle自動(dòng)執(zhí)行恢復(fù)：
SQL> recover database;
ORA-00279: change 18995632784 generated at03/09/2007 15:41:26 needed for thread 1
ORA-00289: suggestion : /oracle/prod/9.2.0/dbs/arch1_6503.dbf
ORA-00280: change 18995632784 for thread 1 isin sequence #6503
Specify log: {<RET>=suggested | filename| AUTO | CANCEL} auto
ORA-00279: change 18995632919 generated at03/09/2007 15:47:01 needed for thread 1
ORA-00289: suggestion : /oracle/prod/9.2.0/dbs/arch1_6504.dbf
ORA-00280: change 18995632919 for thread 1 isin sequence #6504
ORA-00278: log file '/oracle/prod/9.2.0/dbs/arch1_6503.dbf'no longer needed for this recovery
ORA-00279: change 18995652925 generated at03/09/2007 16:01:02 needed for thread 1
ORA-00289: suggestion : /oracle/prod/9.2.0/dbs/arch1_6505.dbf
ORA-00280: change 18995652925 for thread 1 isin sequence #6505
ORA-00278: log file '/oracle/prod/9.2.0/dbs/arch1_6504.dbf'no longer needed for this recovery
Log applied.
Mediarecovery complete.
恢復(fù)完成之后，可以open打開數(shù)據(jù)庫：
SQL> alter database open;
Database altered.
恢復(fù)之后可以驗(yàn)證之前的數(shù)據(jù)：
SQL> select count(*) from eygle.eygle;
COUNT(*)
----------
12
由于控制文件和在線日志文件都沒有損失，數(shù)據(jù)庫執(zhí)行了完全恢復(fù)，數(shù)據(jù)被正確的恢復(fù)了出來。從alert文件中，我們可以看到完整的介質(zhì)恢復(fù)過程，Oracle通過應(yīng)用歸檔日志對數(shù)據(jù)文件進(jìn)行不斷的推進(jìn)恢復(fù)：
Fri Mar 9 16:05:29 2007
ALTERDATABASE RECOVER database
Media Recovery Start
Starting datafile 1 recovery in thread 1sequence 6503
Datafile 1:'/opt/oracle/oradata/eygle/system01.dbf'
Starting datafile 2 recovery in thread 1sequence 6503
Datafile 2: '/opt/oracle/oradata/eygle/undotbs01.dbf'
Starting datafile 3 recovery in thread 1sequence 6503
Datafile 3:'/opt/oracle/oradata/eygle/eygle01.dbf'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASERECOVER database ...
Fri Mar 9 16:05:37 2007
ALTERDATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /opt/oracle/product/9.2.0/dbs/arch1_6503.dbf
ORA-279 signalled during: ALTER DATABASERECOVER CONTINUE DEFAULT ...
Fri Mar 9 16:05:38 2007
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /opt/oracle/product/9.2.0/dbs/arch1_6504.dbf
ORA-279 signalled during: ALTER DATABASERECOVER CONTINUE DEFAULT ...
Fri Mar 9 16:05:38 2007
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /opt/oracle/product/9.2.0/dbs/arch1_6505.dbf
然后根據(jù)日志序列，順序應(yīng)用在線日志文件，完成恢復(fù)：
Recovery of Online Redo Log: Thread 1 Group 3Seq 6506 Reading mem 0
Mem# 0errs 0: /opt/oracle/oradata/eygle/redo03.log
Recovery of Online Redo Log: Thread 1 Group 4Seq 6507 Reading mem 0
Mem# 0errs 0: /opt/oracle/oradata/eygle/redo04.dbf
Recovery of Online Redo Log: Thread 1 Group 5Seq 6508 Reading mem 0
Mem# 0errs 0: /opt/oracle/oradata/eygle/redo05.dbf
Media Recovery Complete
Completed: ALTER DATABASE RECOVER CONTINUE DEFAULT
在Open過程中，Oracle進(jìn)行實(shí)例恢復(fù)，實(shí)例恢復(fù)對日志的掃描是通過兩階段掃描完成的：
Fri Mar 9 16:05:44 2007
alter database open
Fri Mar 9 16:05:44 2007
Beginning crash recovery of 1 threads
Fri Mar 9 16:05:44 2007
Startedfirst pass scan
Fri Mar 9 16:05:44 2007
Completed first pass scan
0 redoblocks read, 0 data blocks need recovery
Fri Mar 9 16:05:44 2007
Startedrecovery at
Thread1: logseq 6508, block 2, scn 4.1815783972
Recovery of Online Redo Log: Thread 1 Group 5Seq 6508 Reading mem 0
Mem# 0errs 0: /opt/oracle/oradata/eygle/redo05.dbf
Fri Mar 9 16:05:44 2007
Completed redo application
Fri Mar 9 16:05:44 2007
Ended recovery at
Thread1: logseq 6508, block 2, scn 4.1815803973
0 datablocks read, 0 data blocks written, 0 redo blocks read
Crashrecovery completed successfully
恢復(fù)完成后，數(shù)據(jù)庫可以成功Open打開。
本次分享的內(nèi)容到此結(jié)束，下期將會(huì)詳細(xì)介紹RMAN備份。今天你備份了嗎？
如何加入"云和恩墨大講堂"微信群
