RMAN还原与恢复

一、 准备工作

1.     分配好新服务器、安装好Oracle软件（配置、目录等最好与原服务器一样）
2.     配置好MML（若已使用）
3.     从备份中恢复了辅助项（PMAN不会备份这些项），包括
4.     数据库网络文件（sqlnet.ora,listener.ora等）
5.     oratab文件（若已使用）
6.     数据库参数文件（若不是spfile的一部分且不会由RMAN备份）
7.     确保适当的RMAN备份集片已经就绪（必须位于RMAN可访问位置、RMAN必须知道这些备份集片位置）

二、 还原spfile

       现在你已经暂存了RMAN备份集片或确保已将它们保存到预期的位置，此时，可准备还原已丢失或者需要替换的数据库部分。首先还原数据库spfile

1.    从运行的数据库内存恢复
       如果误删除数据库spfile，而数据库正在运行，此时最简单的恢复方法是：

Create spfile from memory;
Show parameter spfile

将创建出来的文件移回原spfile位置，并重命名回原名字

2.    使用rman自动控制文件备份+FRA
1)    设置数据库环境
       执行用户环境变量文件
2)    启动RMAN

rman target /

3)    在rman使用startup nomount启动数据库实例

startup nomount

rman可以在无参数文件的情况下打开数据库

4)    提取数据库spfile（默认还原最新的文件）

Restore spfile to '/tmp/spfiletemp.ora' from autobackup recovery area ='/data/prd/fast_recovery_area' db_name=EUPHY;

现在已经为restore spfile命令添加了恢复区域位置和数据库名称作为参数

5)    把/tmp/spfiletemp.ora拷贝到新库参数文件位置，并改成对应名字

cp /tmp/spfiletemp.ora /data/prd/oracle/database/12.2.0.1/Euphy/dbs/spfileeuphy.ora

6)    使用startup force重启数据库（假设只丢了spfile，其他文件完好）

startup force

3.    使用rman自动控制文件备份+非FRA
       我们说过，RMAN必须知道这些备份集片位置才能进行还原。如果没有在FRA中存储控制文件自动备份，RMAN需要获得不同信息（控制文件自动备份存储位置和DBID）才能找到它们，原因在于未使用FRA的标准格式。

1)    设置数据库环境
执行用户环境变量文件
2)    启动RMAN

rman target /

3)    设置要还原的spfile所在数据库的DBID

Set DBID=1145089261;

DBID获取方法：
法1：Select dbid from v$database; 
法2：看控制文件自动备份文件名字（格式为: c-dbid-备份日期-序号），如果有多个，可以用strings命令查看备份文件内容，找出对应数据库名字的备份文件

4)    在rman使用startup nomount启动数据库实例

startup nomount

5)    定义控制文件自动备份位置和文件名格式

Set controlfile autobackup format for device type disk to ‘/u02/backup/%F’;

6)    提取数据库spfile（默认还原最新的文件）

Restore spfile from autobackup;

如果知道从哪个备份集片提取spfile，可以添加from backup子句引用

Restore spfile from ‘/u01/bak/C-2539725638-20060629-00’;

7)    使用startup force重启数据库（假设只丢了spfile，其他文件完好）

startup force

4.    使用恢复目录
Rman会使用恢复目录找出最新的控制文件备份，因此不需使用autobackup参数。

1)    设置数据库环境
执行用户环境变量文件
2)    启动RMAN

rman target sys/sys catalog rcat_manager/password@tnsname

3)    在rman使用startup nomount启动数据库实例

startup nomount

4)    提取数据库spfile（默认还原最新的文件）

Restore spfile;

5)    使用startup force重启数据库（假设只丢了spfile，其他文件完好）

startup force

三、 还原控制文件 

    与还原参数文件类似。还原控制文件前，需要使用正确的spfile启动数据库实例
1.    使用rman自动控制文件备份+FRA
1)    设置数据库环境
执行用户环境变量文件
2)    启动RMAN
rman target /
3)    启动数据库实例到nomount状态
startup nomount
4)    提取数据库控制文件
如果使用FRA，不需要像spfile还原中那样定义FRA位置和数据库名称
Restore controlfile from autobackup;
5)    恢复并打开数据库
alter database mount;
还原及恢复数据文件（如果完好可略过）
Restore database;
Recover database;
如果是noarchivelog模式且有redo log丢失，需要添加noredo参数
Recover database noredo;

Alter database open resetlogs;
Startup force;
2.    使用rman自动控制文件备份+非FRA
如果没有在FRA中存储控制文件自动备份，RMAN需要获得不同信息（控制文件自动备份存储位置和DBID）才能找到它们，原因在于未使用FRA的标准格式
1)    设置数据库环境
执行用户环境变量文件
2)    启动RMAN
rman target /
3)    设置要还原的控制文件所在数据库的DBID
Set DBID=1145089261;
4)    启动数据库实例到nomount状态
startup nomount
5)    定义控制文件自动备份位置和文件名格式
Set controlfile autobackup format for device type disk to ‘/u02/backup/%F’;
6)    提取数据库controlfile（默认还原最新的文件）
Restore controlfile from autobackup;
7)    恢复并打开数据库
Alter database mount;
还原数据文件（如果完好可略过）
Recover database;
如果是noarchivelog模式且有redo log丢失，需要添加noredo参数
Recover database noredo;

Alter database open resetlogs;
Startup force;
3.    在新控制文件中注册数据文件备份和归档备份
将与rman相关的记录还原到控制文件，确保在执行还原操作时，控制文件拥有需要的所有备份记录。以下方法可按需选择：
1)    注册特定备份集片
Catalog backuppiece ‘/u01/backup/备份片名.bkp’;
2)    注册归档日志
Catalog archivelog ‘/u01/backup/归档日志名.arc’;
3)    注册备份目录（常用）
FRA目录
Catalog recovery area;
非FRA目录
Catalog start with ‘/u01/backup’;

四、 还原和恢复数据库（假定spfile和controlfile已恢复）
1.    NOARCHIVELOG模式
从完全的脱机备份中恢复这个数据库，并且不可能实现时间点恢复
1)    假设在本机恢复且已清理原DB数据文件和redo文件（使用FRA）
步骤：
Startup mount
Restore database;
Recover database;
Alter database open resetlogs;
包含resetlogs选项是因为模拟了redo log丢失情况，resetlogs选项将使Oracle在打开数据库时重新创建redo log。从rman角度看，这也创建数据库的新化身。
2)    在不同位置上还原数据库
RMAN默认将数据文件还原到备份时数据文件所在的原始位置，如果新旧位置不同，还原将有问题。
解决方法：Set newname和switch命令。Set newname命令告知rman数据文件原位置和还原后应存放的新位置；switch命令可修改数据库控制文件中数据文件的位置
      
优先顺序如下：
A.    SET NEWNAME FOR DATAFILE and SET NEWNAME FOR TEMPFILE
B.    SET NEWNAME FOR TABLESPACE
C.    SET NEWNAME FOR DATABASE

当使用SET NEWNAME FOR DATAFILE/TEMPFILE的时候，可以使用下面的SQL生成所有的SET NEWNAME命令：
 select 'set newname for datafile ''' || name ||
       ''' to ''<newloc>/' ||
       substr(name, instr(name, '/', -1) + 1) || ''';'
  from v$datafile order by file#;

    当使用FOR TABLESPACE/DATABASE命令的时候，可以指定下面的变量格式：
变量    含义
%b    生成没有任何目录路径信息的文件名
%f    为数据文件建立绝对文件号
%U    由系统生成唯一的文件名，格式为: data-D-%d_id-%I_TS-%N_FNO-%f
%I    生成数据库DBID
%N    生成表空间名

其中前面三个变量必须指定一个，后面2个是可选的。常见的，我们需要保持数据文件一至使用%b即可。

步骤（对数据库中所有数据文件重命名）：
Startup mount
Set newname for database to ‘‘/data/app/datafile/%b;
Restore database;
Recover database;
Switch datafile all;
Alter database open;

#重命名特定表空间数据文件
Set newname for tablespace user_data to ‘/data/app/datafile/user_data%b.dbf’;
#重命名特定数据文件
Set newname for datafile ‘/data/old/datafile/user_data01.dbf’ to ‘/data/new/datafile/user_data01.dbf’;

2.    ARCHIVELOG模式
与非归档模式最大的区别在于归档日志的应用

1)    故障点数据库恢复（完全恢复）
前提：任何未归档的redo日志必须是完好的，否则只能不完全恢复
例子：假设丢失了所有数据文件及控制文件，redo日志完好，使用FRA
步骤：
A.    设置数据库环境
执行用户环境变量文件
B.    启动RMAN
rman target /
C.    启动数据库实例到nomount状态
startup nomount
D.    提取数据库controlfile 
restore controlfile from autobackup;
E.    为还原分配要使用的信道
Allocate channel c1 device type disk;
不需定义位置，因为上一步已经设了
F.    提取数据库controlfile（默认还原最新的文件）
Restore controlfile from autobackup;
G.    启动到mount状态，还原数据库
Alter database mount;
-- 可以先设置好并行度等，比如配置并行度为2
configure device type disk parallelism 2;
Restore database;
--如果准备还原的数据文件已存在，rman不会再还原该文件
H.    恢复并打开数据库
Recover database;
  -- 由于还原了数据文件，需要用resetlogs打开数据库
Alter database open resetlogs;
Startup force;

2)    表空间恢复
Alter tablespace users offline;
Alter tablespace data offline;
Restore tablespace users,data;
Recover tablespace users,data;
Alter tablespace users online;
Alter tablespace data online;

3)    数据文件恢复（可以写文件号或文件名）
Alter database datafile 6 offline;
Alter database datafile ‘/u01/app/user01.dbf’ offline;
Restore datafile 6;
Restore datafile ‘/u01/app/user01.dbf’;
Recover datafile 6;
Recover datafile ‘/u01/app/user01.dbf’;
Alter database datafile 6 online;
Alter database datafile ‘/u01/app/user01.dbf’ online;

五、 联机重做日志丢失恢复
1.    重做日志文件组成员丢失
1)    非活动日志文件组成员丢失
这是最简单的一种情况，使用
Alter database add logfile member命令重建成员（丢失的成员可在alert日志中看到）
2)    活动日志文件组成员丢失
A. 如果数据库未崩溃
--避免数据丢失
Alter system checkpoint;  
--重建重做日志组成员
Alter database add logfile ‘/data/app/logfile/redo02b.log’ reuse to group 2;
B. 如果数据库已崩溃
启动数据库到mount状态如何重建日志组成员，或者，
将未丢失成员复制一份重命名为丢失成员文件，然后再正常启动数据库
2.    非活动联机重做日志组丢失
这也是相对简单的情况，具体分为以下两种情况：
1)    数据库正在启动时丢失
如果部分成员丢失，按照上面情况处理
如果所有成员丢失，则删除该日志组然后重建
Alter database drop logfile group 2;
Alter database add logfile group 2 size 300M;

2)    数据库运行期间丢失
Alter system checkpoint;  
Alter database clear logfile group 2;
若要清除的文件尚未归档，会出现报错ora-350：log 1 需要被归档。由于日志组文件已不存在，当然无法进行归档，此时应该只能强行清除未归档日志文件
Alter database clear unarchived logfile ‘/data/app/logfile/redo02.log’;
未归档数据会丢失，恢复后需要立即备份数据库

3.    活动但非当前联机重做日志组丢失
强行清除未归档日志文件
Alter database clear unarchived logfile ‘/data/app/logfile/redo02.log’;
未归档数据会丢失，恢复后需要立即备份数据库

4.    当前联机重做日志丢失
这是最糟糕的一种情况，一般都会有数据丢失，而数据库无法处于正常状态而关闭。
如果数据库还未异常关闭，立即执行
Alter system checkpoint  以免数据全部丢失，然后尽快关闭数据库。

1)    如果运气好，不需任何恢复可能也能打开数据库：
Startup mount
Alter database clear unarchived logfile ‘/data/app/logfile/redo02.log’;
Alter database open;
如果幸运，数据库将正常打开
2)    如果未打开，将处于糟糕的境地，需要执行数据库不完全恢复（见后面）

高级主题

一、    恢复CDB&PDB
1.    恢复根容器
如果你正好丢失了与根容器相关的一个或多个数据文件，整个数据库很可能停运，最终你只能无奈地在数据库停机时恢复根容器

步骤（假设只有数据文件有问题）：
Startup mount
Restore database root;
recover database root;
alter database open;
当然也可以选择以前面的方法恢复数据文件

2.    恢复种子容器
如果种子容器丢失，仍能成功打开数据库，控制台及alert日志都不会显示错误信息，但可以通过v$recover_file发现是否丢了数据文件，也可以在show pdbs时看到PDB$SEED状态变成了mounted。可能直到创建PDB时，才会真正注意到该问题：Ora-65036：pdb PDB$SEED未以所需模式打开

由于它不影响启动CDB和其他任何PDB，因此不至于停机，可进行联机还原，不过之后需要重启

步骤：
Restore pluggable database “PDB$SEED”;
Recover pluggable database “PDB$SEED”;
 -- these next commands can be run later
Shutdown immediate;
startup

3.    恢复PDB
Rman支持一次恢复一个或多个pdb，恢复过程中不需停止其他pdb
1)    完整恢复PDB
要还原一个完整的pdb，首先必须关闭该pdb；而若恢复表空间或数据文件，这并非是必须的。
下面这个例子一次恢复两个pdb：
rman target=/
alter pluggable database testpdb,tplug close;
restore pluggable database testpdb,tplug;
recover pluggable database testpdb,tplug;
alter pluggable database testpdb,tplug open;

或者连接到pdb进行操作
rman target=sys/sys@pdb1
SHUTDOWN IMMEDIATE;
RESTORE DATABASE;
RECOVER DATABASE;
STARTUP;

2)    恢复PDB表空间
Rman连接到pdb
rman target sys/sys@PDB-TNSNAME
其他跟恢复普通表空间是一样的
Alter tablespace users offline;
Alter tablespace data offline;
Restore tablespace users,data;
Recover tablespace users,data;
Alter tablespace users online;
Alter tablespace data online;

3)    恢复PDB数据文件
Rman连接到pdb
rman target sys/sys@PDB-TNSNAME
同样其他跟恢复普通数据文件是一样的
Alter database datafile 6 offline;
Alter database datafile ‘/u01/app/user01.dbf’ offline;
Restore datafile 6;
Restore datafile ‘/u01/app/user01.dbf’;
Recover datafile 6;
Recover datafile ‘/u01/app/user01.dbf’;
Alter database datafile 6 online;
Alter database datafile ‘/u01/app/user01.dbf’ online;

二、    在非CDB和整个CDB执行不完全恢复
1.    含义
不完全恢复也称为时间点恢复（Point-In-Time Recovery,PITR），会影响整个数据库。你不能只对数据库的一部分执行不完全恢复，那会导致恢复的那部分数据与数据库其他部分SCN号不同。

不完全恢复具有四种不同类型：
    基于时间的恢复
    基于SCN的恢复
    基于更改的恢复
    基于还原点的恢复
你必须将整个数据库还原到同一个时间点

2.    原理
1)    执行restore database指出还原时间点（定义时间/SCN/日志更改号/还原点）
        Rman根据你指定的时间点，还原完成时间最接近的数据库备份
2)    执行recover database指出恢复时间点（定义时间/SCN/日志更改号/还原点）
    Rman将应用所需的增量备份和归档日志，将数据库恢复到所需时间点
3)    使用alter database open resetlogs命令打开数据库
    不完全恢复始终需要resetlogs打开数据库。Oracle将清除redo日志，使数据库做好准备支持将要创建的数据库新化身。
    化身代表给定数据库的逻辑生命周期。在创建数据库时启动第一个化身，当使用resetlogs命令打开数据库时，该化身终结。随后的每一个化身都以使用resetlogs命令打开数据库为界。
    可查询v$database_incarnation视图查看每个化身
4)    打开后尽快备份数据库

3.    创建恢复点
恢复目标是恢复进程的终点，通常我们基于定义时间/SCN/日志更改号/还原点来标识它。有许多不同的方法创建恢复点：
1)    Run代码块使用set命令
Run
{
Set until time “to_date(‘07/01/14 15:00:00’,’mm/dd/yy hh24:mi:ss’)”;
Restore database;
Recover database;
alter database open resetlogs;
}
2)    可以在restore和recover命令中直接使用until命令
Startup mount;
Restore database until time “to_date(‘07/01/14 15:00:00’,’mm/dd/yy hh24:mi:ss’)”;
Recover database until time “to_date(‘07/01/14 15:00:00’,’mm/dd/yy hh24:mi:ss’)”;
alter database open resetlogs;

4.    基于时间的恢复
上面的例子即使基于时间点的恢复。需要注意的是，你指出的还原点是一个近似值，数据库的实际还原点时间点基于SCN，时间偏差约为3分钟。
5.    基于SCN的恢复
   准确，但未必常用
Startup mount;
Restore database until SCN 10000;
Recover database until SCN 10000;
alter database open resetlogs;

6.    基于更改的恢复
    恢复到指定序列号的归档日志（不包括指定到的日志序列，开区间）
Startup mount;
Restore database until sequence 100 thread 1; --不包括100号
Recover database until sequence 100 thread 1; --不包括100号
alter database open resetlogs;

7.    基于还原点的恢复
1)    创建还原点
Create restore point test_001;
为避免还原点过时（最多维护2048个），可使用有保障的还原点
Create restore point test_001 guarantee flashback database;
可用v$restore_point视图确定还原点

2)    步骤：
Startup mount;
Restore database until restore point test_001;
Recover database until restore point test_001;
alter database open resetlogs;

也可以使用run代码块
Startup mount;
Run
{
Set until restore point test_001;
Restore database test_001;
Recover database test_001;
}
alter database open resetlogs;

三、    执行PDB的不完全恢复
1.    关于PDB的时间点恢复(PITR)
首先rman需要创建一个辅助数据库，为此，rman需要还原所需的数据文件来启动和打开辅助实例。与这些表空间相关的数据文件默认存储在fra中，若未定义fra，则在执行recover命令时，必须定义要创建的文件位置。
还原表空间时，将包括system、sysaux和undo表空间，这些是启动辅助实例所需的基本表空间。另外，也还原与pdb相关的表空间。
还原非CDB或整个CDB时，只需要为还原的数据库文件及执行还原所需的归档文件准备空间。而在PDB PITR中，需要准备数据库数据文件占用的所有空间以及创建辅助数据库需要的所有空间。这意味着，PDB PITR很可能需要大量空间。
2.    限制和要求
1)    在rman执行PDB PITR时，会创建一个辅助实例。这个辅助实例使用FRA（或auxiliary destination参数定义的位置）来存储将要创建的数据文件从而执行恢复。若未定义FRA，则在执行recover命令时，必须使用auxiliary destination定义要创建的文件位置。
2)    将PDB还原到不同时间点也会影响在整个CDB上使用闪回数据库的能力。如果将PDB还原到不同的时间点，你只能将数据库从当前时间点闪回到该PDB还原时间点（可以有一些方法绕过该限制，后面会提及）。
3)    PDB PITR仅要求关闭正在恢复的PDB，其余部分正常运行。
4)    务必准备足够的磁盘空间，还要确保用于创建辅助实例文件的os目录拥有适当权限。
5)    如果还原或恢复操作失败，务必在失败后完全清除辅助实例。
A.    连接到辅助实例，执行drop database命令将其从系统中删除
B.    清除与辅助实例相关的某些元数据设置
Dbms_backup_restore.manageAuxInstance(‘{automatic_instance_name}’,1)
3.    基于时间恢复PDB
1)    使用FRA
rman target=/

RUN {
  ALTER PLUGGABLE DATABASE pdb1 CLOSE;
  SET UNTIL TIME "TO_DATE('23-DEC-2013 12:00:00','DD-MON-YYYY HH24:MI:SS')";
  RESTORE PLUGGABLE DATABASE pdb1;
  RECOVER PLUGGABLE DATABASE pdb1;
  ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;
}
2)    不使用FRA
rman target=/

ALTER PLUGGABLE DATABASE pdb1 CLOSE;
RESTORE PLUGGABLE DATABASE pdb1 UNTIL TIME "TO_DATE('23-DEC-2013 12:00:00','DD-MON-YYYY HH24:MI:SS')";
RECOVER PLUGGABLE DATABASE pdb1 UNTIL TIME "TO_DATE('23-DEC-2013 12:00:00','DD-MON-YYYY HH24:MI:SS')" AUXILIARY DESTINATION ‘/data/aux_dest’;
ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;

4.    基于SCN恢复PDB
run 
{
   ALTER PLUGGABLE DATABASE pdb1 CLOSE;
   SET UNTIL SCN 1066;
   RESTORE PLUGGABLE DATABASE pdb1;
   RECOVER PLUGGABLE DATABASE pdb1;
   ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;
}
5.    基于更改恢复PDB
Run
{
ALTER PLUGGABLE DATABASE pdb1 CLOSE;
set until sequence 80;
restore pluggable database pdb1;
recover pluggable database pdb1 auxiliary destination '/u03/temp_pdb';
ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;
}

6.    基于还原点恢复PDB
1)    创建还原点
Create restore point test_001;
为避免还原点过时（最多维护2048个），可使用有保障的还原点
Create restore point test_001 guarantee flashback database;
可用v$restore_point视图确定还原点
2)    步骤：
ALTER PLUGGABLE DATABASE pdb1 CLOSE;
Restore pluggable database to restore point test_001;
Recover pluggable database to restore point test_001;
ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;

四、    其他主题
1.    只读表空间恢复
默认情况下，即使丢失只读数据文件，rman也不会在执行完整数据库还原操作时还原只读数据文件，而需要额外指定参数：
Restore database check readonly;   或
Restore database check force;
执行recover tablespace或recover datafile时，不论是否只读都会进行恢复
2.    归档重做日志的还原
Restore archivelog all;
Restore archivelog from logseq=20 thread=1;
Restore archivelog from logseq=20 until logseq=30 thread=1;

也可以还原到默认位置以外的位置，由于set没有替代方法，所以必须要用run代码块
Run
{
Set archivelog destination to ‘/data/archivelog’;
Restore archivelog all;
}
3.    数据文件副本还原
Restore (datafile 5) from datafilecopy;
Restore datafile 5;
Sql “alter database datafile 5 online;”
4.    恢复受损数据块
遇到报错ora-01578:ORACLE data block corrupted(file # 19,block # 44)

我们可以通过块介质恢复（Block Media Recovery,BMR）来修复坏块
Recover datafile 19 block 44;
如有必要，可同时修复多个文件多个块
Recover 
datafile 19 block 44
datafile 19 block 43
datafile 18 block 44,66,150;

查看rman检测到的所有数据库损坏：
backup validate database;

联机修复数据块
Recover corruption list;
修复后再次检测确保不存在其他受损块

5.    恢复到前一个化身
1)    奇怪的还原需求：
需要使用上次执行resetlogs命令打开数据库前的一个备份来还原数据库，或者可能还需要到执行上一个resetlogs命令之前的时间点。
2)    准备还原
要还原到前一个化身，需要了解要还原的化身，了解可使用哪些还原：
List incarnation of database;
如果你尝试还原到早于当前数据库化身的时间点，通常会遇到报错
RMAN-20208: UNTIL CHANGE is before RESETLOGS change
要执行此还原，需要告知RMAN你真正要恢复到的化身。
3)    执行还原
A.    启动数据库到nomount状态
Startup nomount
B.    还原与要还原的化身相关的控制文件
Run
{
Set until time "to_date('2019-01-07 06:15:07','yyyy-mm-dd hh24:mi:ss')";
Restore controlfile from autobackup;
}
C.    重置数据库化身
Alter database mount;
Reset database to incarnation 2;
D.    基于需要的还原时间执行还原和恢复
Run
{
Set until scn 3318383;
Restore database force;
Recover database;
}
E.    打开数据库
Alter database open resetlogs;

五、    表和分区时间点恢复
12c中引入了新特性，支持单独数据库表和单独表分区的时间点还原
1.    前提条件
1)    源库处于Archivelog模式
2)    要恢复单独分区，必须将compatible参数设置为11.1.0或更高
3)    必须拥有SYSTEM,SYSAUX,UNDO表空间的rman备份
4)    包含要还原对象的表空间的一个或多个备份必须是可用的
5)    必须拥有从用于恢复对象的备份开始-尝试还原的时间点之间的所有归档日志
6)    目标数据库（用于还原表或分区的数据库）必须以只读模式打开
7)    目标数据库也必须处于archivelog模式

2.    限制
1)    不能还原属于sys模式的表
2)    不能还原存储于system和sysaux表空间中的表
3)    不能还原备用数据库中的表分区
4)    不能在备用数据库执行这些还原
5)    如果表有not null约束，则不能使用remap选项将表还原为不同名称

3.    还原原理
首先执行restore命令，rman首先创建辅助数据库，然后从以前完成的物理备份将所有需要的表空间还原到该数据库。Rman仅还原system,sysaux,undo和sysext表空间（如果存在），以及包含要还原的特定对象的表空间。
Rman还原辅助数据库后，将数据库前滚到你在restore命令中指定的时间点，接着创建要还原对象的Oracle data dump导出。创建导出后，可以由rman也可以由自己导入目标数据库。完成操作后，rman将清理辅助数据库。
4.    一个栗子
启动还原前，需要确定在何处保存与与辅助数据库相关的文件
还需要确定对象是用回以前的名字还是新名字
确定以后，执行以下命令（非PDB）
recover table scott.emp,scott.dept
until time "TO_DATE('2016-10-31 17:25:38','yyyy-mm-dd hh24:mi:ss')" auxiliary destination '/app/backup/aux'
datapump destination '/app/backup/dmp'
remap table scott.emp:rest_emp,scott.dept:rest_dept;

如果从pdb还原，还需要包括pdb名
recover table scott.emp,scott.dept
of pluggable database testpdb
until time "TO_DATE('2016-10-31 17:25:38','yyyy-mm-dd hh24:mi:ss')" auxiliary destination '/app/backup/aux'
datapump destination '/app/backup/dmp'
remap table scott.emp:rest_emp,scott.dept:rest_dept;

六、    表空间时间点恢复（TSPITR）
TSPITR使用Oracle辅助实例了创建临时工作区域，DBA可在不同于数据库其余部分的时间点还原数据库中的表空间。这可能导致数据库数据在逻辑上不一致，但在Oracle看来，会认为在还原后数据库处于完全一致状态。
1.    准备工作
1)    确定还原的时间点
如果没有使用恢复目录，表空间的恢复是一次性过程（如果选错了时间点，不能重新尝试恢复），使用恢复目录则无此限制。
2)    确保传送集中的对象是独立的
使用TS_PITR_CHECK视图确认恢复集是完整的，并标识所有要用到的其他表空间。
Eg:检查表空间TEST_RECOVER是否依赖其他表空间
SELECT obj1_owner,obj1_name,obj1_type,reason FROM SYS.TS_PITR_CHECK WHERE (TS1_NAME IN ('TEST_RECOVER') AND TS2_NAME NOT IN ('TEST_RECOVER')) OR (TS1_NAME NOT IN ('TEST_RECOVER') AND TS2_NAME IN ('TEST_RECOVER'));
如果不返回任何行，则ok，否则需要通过reason字段查看具体原因

3)    保存可能在恢复过程中丢失的数据
Oracle提供了视图TS_PITR_OBJECTS_TO_BE_DROPPED，可以列出将在恢复操作期间丢失的所有对象。
Select * from TS_PITR_OBJECTS_TO_BE_DROPPED where tablespace_name=’ TEST_RECOVER’;
2.    实际执行
Alter tablespace TEST_RECOVER offline;

Recover tablespace TEST_RECOVER 
until time "to_date('2019-01-07 06:15:07','yyyy-mm-dd hh24:mi:ss')"
auxiliary destination ‘/data/app/aux_dest’;

Alter tablespace TEST_RECOVER offline;

注意事项：
1)    可选参数auxiliary destination指示rman和Oracle在何处创建与辅助数据库关联的文件。若使用该参数，该恢复称为具有自动化实例的自定义TSPITR；若不使用，则称为完全自动的TSPITR
2)    auxiliary destination指示的目录应该已存在并且Oracle能够写入，另外目录路径最后一定不要有斜杠，否则TSPITR会失败且错误描述难以判断

清理辅助实例：
Exec dbms_backup_restore.manageauxinstance(‘辅助实例SID’),1);

参考：
https://docs.oracle.com/database/121/BRADV/rcmadvre.htm#BRADV008