在oracle10g 10.2.0.1上測試不完全恢復_recover database until scn

群友談到測試不完全恢復與自己預測結果不符，遂動手進行如下測試:

1,構建測試使用者及專用表空間zxy
create tablespace zxy datafile 'c:\zxy.dbf' size 10m;
create user zxy identified by system default tablespace zxy account unlock;
grant resource,connect to zxy;
2,以zxy使用者身份構建表tt,同時插入資料
conn zxy/system
create table tt(a int);
insert into tt values(1);
commit;
conn /as sysdba
alter system switch logfile;
alter system archivelog current;
3,透過rman對資料庫進行一個全備(一併備份所有的歸檔日誌及控制檔案）
  rman target /
  backup database format 'c:\%d_%u_fulldbbak' tag='fulldbbak';

  backup current controlfile format 'c:\%d_%u_contolfilebak' tag='controlbak';
    --因為在實際生產環境中,當你備份後，資料庫結構及相關內容是一直動態變化的，我一會還原恢復時，是從這個控制檔案備份為基礎的


  backup archivelog all delete input format 'c:\%d_%u_archivebak' tag='archbak';

4,為了實行不完全恢復，登陸資料庫檢視dbid及current_scn
   ---大家可以想下，為何要它們的資訊，因為當你採用控制檔案備份，恢復控制檔案時，此時要恢復的目標資料庫並沒有載入controlfile(它儲存dbid及current_scn)，所以要得到它的資訊，你必須手工指定它們
   sqlplus '/as sysdba'
   select current_scn,dbid from v$database;
5,為了模擬生產環境的資料變更，繼續建立表空間及使用者haha，並插入測試資料
create tablespace haha datafile 'c:\ha1.dbf' size 10m;
create user haha identified by system default tablespace haha account unlock;
grant resource,connect to zxy;
conn haha/system
create table ha1(a varchar(2));
insert into ha1 values('xi');
commit;
conn /as sysdba
alter system switch logfile;
alter system archivelog current;


6,dba一個drop tablespace或者損壞zxy使用者的對應動作，馬上恢復zxy使用者對應的資料（注意：不含之後建立的haha使用者資料）
    分為幾個小步驟：
       a,rman target /
       b,set dbid=第4步查到的dbid;要不然會報錯
       c,restore controlfile from '第3步控制檔案備份的具體路徑';
           --注：你要透過from tag會報錯，原因很簡單，備份資訊儲存在控制檔案中， 此時控制檔案未開啟
        d,alter database mount;--mount 資料庫，為下面工作打好基礎
        e,restore database;--還原資料庫，維護觀察過程，就是應用以上全庫備份的過程
        f,recover database until scn ' 第4步查到的scn';--大量應用歸檔及線上日誌
        g,sql 'alter database open resetlogs';--不完全恢復後，必須以resetlogs開啟資料庫


後記：
     不完全恢復，請馬上對資料庫進行全庫備份，因為之前的備份全然失效
      透過此測試，我們可以發現，沒有配置catalog庫的生產庫或者測試庫，一旦出故障，是多麼的脆弱及恢復麻煩