    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相互验证加深理解。

ITPub博客

实战10g新特性之RMAN TSPITR特性

最新文章