    10g以前對於資料丟失或者人為導致的邏輯錯誤時我們會用資料庫級別的不完全恢復來解決，而到了10g之後，RMAN推出了一個新的特性叫"tablespace point-in-time recovery "，簡稱TSPITR，其實就是可以實現表空間級別的不完全恢復，當然我們知道到了10g之後flashback特性也可以解決上述問題。由於之前沒玩過這個特性，於是來實戰一把整個操作過程(具體原理部分請參考Database Backup and Recovery Advanced User's Guide文件)
    1.模擬環境
     1.1建立測試表空間以及測試物件
     [oracle@sourcedb oradata]$ sqlplus / as sysdba
     SQL> create tablespace test_tspitr datafile '/oradata/wilson/test_tspitr01.dbf' size 10M;
     SQL> create table test(id int);
     SQL> begin
   for i in 1..10 loop
   insert into test values(i);
   end loop;
   commit;
   end;
   /
     1.2備份資料庫
     [oracle@sourcedb oradata]$ rman target /
     RMAN> backup database format '/tmp/dbf_%U' plus archivelog format '/tmp/arch_%U' delete input;
     1.3模擬誤刪除資料
     SQL> select count(*) from test;

     COUNT(*)
     ----------
              10

SQL> delete test;

SQL> commit;

SQL> select count(*) from test;

    COUNT(*)
     ----------
               0

    2.確定TSPITR的目標時間
    這裡有多種方法，比如使用flashback query,logmnr等，我這裡是透過flashback qery確認的。
    SQL> select count(*) from test;

    COUNT(*)
     ----------
               0
    SQL> select count(*) from test as of timestamp to_timestamp('2013-02-23 21:40:34','YYYY-MM-DD:HH24:MI:SS');
    COUNT(*)
     ----------
               10

    3.解決需要recover的表空間中的依賴關係
    如果玩個傳輸表空間的話知道里面有個要求是表空間必須為自包含，這裡所說的依賴關係與其類似。

3.1識別依賴關係

     SQL>conn / as sysdba
     SQL>SELECT * FROM SYS.TS_PITR_CHECK
     WHERE (
        TS1_NAME IN ('TEST_TSPITR')
        AND TS2_NAME NOT IN ('TEST_TSPITR')
                     );
own1   name1 subname1 obj1type ts1_na    name2     subname2 obj2type own2   ts2_na cname reason
------ ----- -------- -------- --------- --------- -------- -------- ------ ------ ----- -------------------------
SCOTT TEST           TABLE    TEST_TSPITR TEST_IDX          INDEX    SCOTT USERS        Tables and  associated
                                                                                                                                                                   indexes not fully
                                                                                                                                                                contained in the
                                                                                                                                                                  recovery set
     從以上輸出可以判斷test表的索引test_idx與表不在同一表空間內。
     3.2解決依賴關係

     方法有二種，第一干掉索引，第二將索引表空間加到恢復佇列中，這裡我選擇第一種。
     SQL> drop index test_idx;

    4.識別TSPITR後需要儲存的物件
    當rman對某個表空間進行TSPITR後，對於恢復到的目標時間之後所建立的物件將會丟失，這裡可以透過expdp/impdp工具事先匯出儲存。
    SQL>SELECT OWNER, NAME, TABLESPACE_NAME,
              TO_CHAR(CREATION_TIME, 'YYYY-MM-DD:HH24:MI:SS')
    FROM TS_PITR_OBJECTS_TO_BE_DROPPED
    WHERE TABLESPACE_NAME IN ('TEST_TSPITR')
    AND CREATION_TIME > TO_DATE('2013-02-23 21:40:34','YYYY-MM-DD:HH24:MI:SS')
    ORDER BY TABLESPACE_NAME, CREATION_TIME;

OWNER      NAME       TABLESPACE_NAME      TO_CHAR(CREATION_TI
---------- ---------- -------------------- -------------------
SCOTT      TEST2      TEST_TSPITR          2013-02-23:21:41:25
    從輸出結果發現物件test2是在恢復的目標時間之後建立的，用資料泵匯出儲存這裡不再演示。

    5.執行全自動的RMAN TSPITR(共有3種TSPITR恢復方式，這種方式是oracle推薦的也是最簡單的)
    [oracle@sourcedb oradata]$ rman target / cmdfile=cmd.sh log=cmd.log
    [oracle@sourcedb oradata]$ cat cmd.sh
    run {
recover tablespace test_tspitr until time "TO_DATE('2013-02-23 21:40:34','YYYY-MM-DD:HH24:MI:SS')" auxiliary destination '/oradata/aux';
           }

    6.驗證結果
     6.1將表空間online

     SQL>alter tablespace test_tspitr online;
     SQL>select count(*) from scott.test;
     COUNT(*)
     ----------
              1 0

ok,實驗成功，對於TSPITR的原理的理解可以先通讀oracle官方文件，然後結合rman的恢復日誌cmd.log相互驗證加深理解。

實戰10g新特性之RMAN TSPITR特性

相關文章