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

Oracle 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;

Oracle 深入解析10053事件ORA-16038的解决相关资讯 RMAN Oracle 10g新特性

RMAN故障一例（归档的备份，从不（今 20:42）
RMAN的FORMATA格式说明（03月10日）
Oracle 11g RMAN复制数据库的测试（01月19日）

RMAN数据库迁移（05月22日）
使用RMAN复制恢复开发库环境（02月17日）
Oracle 11g RMAN跨平台传输表空间（01月19日）

本文评论查看全部评论（0）