tspitr功能的测试

10g就有了以【表空间为单位】的定点恢复，这里测试如下


targetdb自然必须是archive模式才可以，并且恢复后，恢复点以后的原来rman备份的的东西都不在有用，【没使用catalog的情况下，只能恢复一次，恢复后不能再次恢复】，这的确不是件好事(所以还是flashbackup table好用)。tspitr流程大概就是创建启用辅助(auxiliary)db，将数据按点clone到辅助db上，在辅助db上resetlog open后，将表空间的数据和词典倒腾(expdp,impdp)回来。

tspitr不能恢复直接删除或者重新命名后的表空间。

准备工作。
1。要恢复，要求恢复的表空间必须是自包含的。
select *
from ts_pitr_check
where (ts1_name = 'ZYZ' and ts2_name <> 'ZYZ')
or (ts1_name <> 'ZYZ' and ts2_name = 'ZYZ')
检查一下，如果有和别的表空间关联，也需要一起恢复。
2。恢复到某一个点后，这个点以后创建的objet都会没有了，可以查看一下是哪些object，必要的情况下，先export出来
select owner, name, tablespace_name, creation_time
from ts_pitr_objects_to_be_dropped
where tablespace_name = 'ZYZ'
and creation_time > '15-04-18'
这里，我的NLS_DATE_FORMAT是RR-MM-DD

开始恢复
恢复有3个模式，内容基本一样，
1。rman全自动
recover tablespace zyz until time "TO_DATE('2015-04-19','YYYY-MM-DD')" auxiliary destination '/ORADATA/aux'
 过程中，虽然targetdb的instance没有重新启动，但是在最后的impdb时，ZYZ是offline了再impdb的后再online的，看target的alertlog里面有
alter tablespace ZYZ offline immediate
drop tablespace  ZYZ including contents keep datafiles
DM00 started with pid=40, OS id=29123, job SYS.TSPITR_IMP_Bogq
Plug in tablespace ZYZ with datafile
  '/ORADATA/app/oradata/orcl11g/zyz01.dbf'
alter tablespace  ZYZ read write
alter tablespace  ZYZ offline
也就是最后没将它online，我们还得手动将表空间online
执行alter tablespace  ZYZ online
2. rman clone instance，但是可以修改修改run的script。
3.全都自己搞