基于時間點的不完全恢復(fù)的例子

說到不完全恢復(fù)，一般有三種場景，基于時間點的不完全恢復(fù)，基于scn的不完全恢復(fù)，基于cancel的不完全恢復(fù)。 三種情況都是不完全

說到不完全恢復(fù)，一般有三種場景，基于時間點的不完全恢復(fù)，基于scn的不完全恢復(fù)，基于cancel的不完全恢復(fù)。
三種情況都是不完全恢復(fù)采用的方式，而不完全恢復(fù)都是在完全恢復(fù)的過程中出現(xiàn)了這樣那樣的錯誤，數(shù)不勝數(shù)，基本就是歸檔，redo損壞丟失，控制文件丟失，備份的問題，手工失誤等等。
我們可以舉一個不完全恢復(fù)的案例，其實在實際操作的過程中還是有一些值得總結(jié)和學(xué)習(xí)的地方。
第一步準備基本的數(shù)據(jù)。目前我們可以看到在表空間data上只有一個表new_recover

SQL> select owner,segment_name,segment_type from dba_segments where tablespace_name='DATA';

OWNER SEGMENT_NAME SEGMENT_TYPE
TEST NEW_RECOVER TABLE
里面有一些數(shù)據(jù)。

SQL> select count(*)from test.new_recover;

COUNT(*)
----------
4667
第二步開始熱備份，為了明白整個過程，我們手工來完成這個不完全恢復(fù)。
使用下面的語句生成熱備份的動態(tài)sql
select 'alter tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where l
ogging='LOGGING';
然后拷貝物理文件到指定的備份目錄即可。
拷貝完成之后，使用下面的語句聲明完成了熱備份
select 'alter tablespace '||tablespace_name||' end backup;' from dba_tablespaces where l
ogging='LOGGING';
第三步我們開始刪除表空間data，然后停掉數(shù)據(jù)庫開始嘗試恢復(fù)。
drop tablespace data including contents and datafiles;
shut immediate
刪除之后，不要擔(dān)心自己沒記下時間戳，其實在數(shù)據(jù)庫日志里面會有記錄。
Sun Jul 26 19:29:37 2015
drop tablespace data including contents and datafiles
Deleted file /u02/ora11g/oradata/TEST/data01.dbf
Completed: drop tablespace data including contents and datafiles
Sun Jul 26 19:29:54 2015
第四步我們開始嘗試還原數(shù)據(jù)文件
我們把數(shù)據(jù)文件從熱備份的路徑還原到數(shù)據(jù)文件的路徑下
startup mount
!cp xxxx/hot_backup/*.dbf /u02/ora11g/oradata/TEST

第五步我們可以嘗試開始基于時間點的恢復(fù)，基于時間點的這種恢復(fù)就是不完全恢復(fù)了，因為時間點之后的數(shù)據(jù)變更就會丟失。

SQL> recover database until time '2015-07-26 19:29:37';
Media recovery complete.
恢復(fù)的過程很快就會完成。這個時候刪除的數(shù)據(jù)文件還沒有體現(xiàn)在控制文件里面，在v$datafile里也看不到。
SQL> Select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u02/ora11g/oradata/TEST/system01.dbf
/u02/ora11g/oradata/TEST/sysaux01.dbf
/u02/ora11g/oradata/TEST/undotbs01.dbf
/u02/ora11g/oradata/TEST/testdata.dbf
第6步我們把數(shù)據(jù)庫使用resetlogs的方式打開

SQL> alter database open resetlogs;

Database altered.

這個時候去查看v$datafile就會發(fā)現(xiàn)多了一個陌生的文件。但是從名字我們看出來提示我們是曾經(jīng)丟失的一個文件，但是不知道怎么回事就給恢復(fù)回來了。
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u02/ora11g/oradata/TEST/system01.dbf
/u02/ora11g/oradata/TEST/sysaux01.dbf
/u02/ora11g/oradata/TEST/undotbs01.dbf
/u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004
/u02/ora11g/oradata/TEST/testdata.dbf
這個時候去嘗試ls -l查看文件是否存在，發(fā)現(xiàn)沒有這個文件。
SQL> !ls -l /u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004
ls: /u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004: No such file or directory
我們先把這個文件給rename一下。

alter database rename file '/u02/ora11g/product/11.2.0/dbhome_1/dbs/MISSING00004' to '/ora11g/oradata/TEST/data01.dbf';

Database altered.
第七步我們開始恢復(fù)這個數(shù)據(jù)文件
恢復(fù)的時候很可能提示你選擇恢復(fù)的方式，我們還是選擇auto

SQL> recover datafile '/u02/ora11g/oradata/TEST/data01.dbf';
ORA-00279: change 970750 generated at 07/26/2015 19:26:36 needed for thread 1
ORA-00289: suggestion :
/u02/ora11g/product/11.2.0/dbhome_1/dbs/arch1_1_886076275.dbf
ORA-00280: change 970750 for thread 1 is in sequence #1

Specify log: {=suggested | filename | AUTO | CANCEL}
auto
Log applied.
Media recovery complete.
恢復(fù)完成之后，查看v$recover_file看看是否還有其它數(shù)據(jù)文件需要恢復(fù)。

SQL> select *from v$recover_file;

no rows selected
恢復(fù)之后查看表空間的狀態(tài)，顯示是online,但是實際上還不是。

SQL> select tablespace_name,status from dba_tablespaces;

TABLESPACE_NAME STATUS
------------------------------ ---------
SYSTEM ONLINE
SYSAUX ONLINE
UNDOTBS ONLINE
TEMP ONLINE
DATA ONLINE
TESTDATA ONLINE

因為這個時候我們查看數(shù)據(jù)還是有問題的。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com