基於時間點的不完全恢複的例子

基於時間點的不完全恢複的例子

說到不完全恢複，一般有三種情境，基於時間點的不完全恢複，基於scn的不完全恢複，基於cancel的不完全恢複。
 三種情況都是不完全恢複採用的方式，而不完全恢複都是在完全恢複的過程中出現了這樣那樣的錯誤，數不勝數，基本就是歸檔，redo損壞丟失，控制檔案丟失，備份的問題，手工失誤等等。
 我們可以舉一個不完全恢複的案例，其實在實際操作的過程中還是有一些值得總結和學習的地方。
 第一步準備基本的資料。目前我們可以看到在資料表空間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
裡面有一些資料。

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

  COUNT(*)
 ----------
      4667
第二步開始熱備份，為了明白整個過程，我們手工來完成這個不完全恢複。
 使用下面的語句產生熱備份的動態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，然後停掉資料庫開始嘗試恢複。
drop tablespace data including contents and datafiles;
 shut immediate
刪除之後，不要擔心自己沒記下時間戳記，其實在資料庫日誌裡面會有記錄。
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
第四步我們開始嘗試還原資料檔案
 我們把資料檔案從熱備份的路徑還原到資料檔案的路徑下
startup mount
 !cp xxxx/hot_backup/*.dbf  /u02/ora11g/oradata/TEST

第五步我們可以嘗試開始基於時間點的恢複，基於時間點的這種恢複就是不完全恢複了，因為時間點之後的資料變更就會丟失。

SQL> recover database until time '2015-07-26 19:29:37';
 Media recovery complete.
恢複的過程很快就會完成。這個時候刪除的資料檔案還沒有體現在控制檔案裡面，在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步我們把資料庫使用resetlogs的方式開啟

SQL> alter database open resetlogs;

Database altered.

這個時候去查看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/product/11.2.0/dbhome_1/dbs/MISSING00004
 /u02/ora11g/oradata/TEST/testdata.dbf
這個時候去嘗試ls -l查看檔案是否存在，發現沒有這個檔案。
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.
第七步我們開始恢複這個資料檔案
 恢複的時候很可能提示你選擇恢複的方式，我們還是選擇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: {<RET>=suggested | filename | AUTO | CANCEL}
 auto
 Log applied.
 Media recovery complete.
恢複完成之後，查看v$recover_file看看是否還有其它資料檔案需要恢複。

SQL> select *from v$recover_file;

no rows selected
恢複之後查看錶空間的狀態，顯示是online,但是實際上還不是。

SQL> select tablespace_name,status from dba_tablespaces;

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

因為這個時候我們查看資料還是有問題的。

SQL> select count(*)from test.new_recover;
 select count(*)from test.new_recover
                          *
 ERROR at line 1:
 ORA-00376: file 4 cannot be read at this time
 ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data01.dbf'

第八步我們把資料表空間置為Online，整個恢複的過程就完成了。
SQL> alter tablespace data online;

Tablespace altered.

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

  COUNT(*)
 ----------
      4667

在整個不完全的恢複過程中碰到了不少的Ora錯誤，有些錯誤是自己的問題從一個演變為另外一個錯誤，最終導致不可恢複。不管怎麼樣從這個過程中還是能夠看到在資料恢複的過程中，Oracle還是做了很多的工作來保證了資料恢複成為可能。