目录
一、 准备工作
分配好新服务器、安装好Oracle软件(配置、目录等最好与原服务器一样)
配置好MML(若已使用)
从备份中恢复了辅助项(PMAN不会备份这些项),包括:数据库网络文件(sqlnet.ora,listener.ora等)、oratab文件(若已使用)、参数文件、控制文件等
确保适当的RMAN备份集片已经就绪(必须位于RMAN可访问位置、RMAN必须知道这些备份集片位置)
二、 还原spfile
现在你已经暂存了RMAN备份集片或确保已将它们保存到预期的位置,此时,可准备还原已丢失或者需要替换的数据库部分。首先还原数据库spfile
- 从运行的数据库内存恢复
如果误删除数据库spfile,而数据库正在运行,此时最简单的恢复方法是:
Create spfile from memory;
Show parameter spfile
将创建出来的文件移回原spfile位置,并重命名回原名字
- 使用rman自动控制文件备份+FRA
1)启动RMAN
rman target /
2)在rman使用startup nomount启动数据库实例
startup nomount
rman可以在无参数文件的情况下打开数据库
3)提取数据库spfile(默认还原最新的文件)
Restore spfile to '/tmp/spfiletemp.ora' from autobackup recovery area ='/data/prd/fast_recovery_area' db_name=EUPHY;
现在已经为restore spfile命令添加了恢复区域位置和数据库名称作为参数
4)把/tmp/spfiletemp.ora拷贝到新库参数文件位置,并改成对应名字
cp /tmp/spfiletemp.ora /data/prd/oracle/database/12.2.0.1/Euphy/dbs/spfileeuphy.ora
5)使用startup force重启数据库(假设只丢了spfile,其他文件完好)
startup force
- 使用rman自动控制文件备份+非FRA
我们说过,RMAN必须知道这些备份集片位置才能进行还原。如果没有在FRA中存储控制文件自动备份,RMAN需要获得不同信息(控制文件自动备份存储位置和DBID)才能找到它们,原因在于未使用FRA的标准格式。
1)启动RMAN
rman target /
2)设置要还原的spfile所在数据库的DBID
Set DBID=1145089261;
DBID获取方法:
Select dbid from v$database;
或者看控制文件自动备份文件名(格式为: c-dbid-备份日期-序号)
如果有多个实例,可以用strings命令查看自动备份文件内容,找出对应数据库名字的备份文件
3)在rman使用startup nomount启动数据库实例
startup nomount
4)定义控制文件自动备份位置和文件名格式
Set controlfile autobackup format for device type disk to '/u02/backup/%F';
5)提取数据库spfile(默认还原最新的文件)
Restore spfile from autobackup;
如果知道从哪个备份集片提取spfile,可以添加from backup子句引用
Restore spfile from '/u01/bak/C-2539725638-20060629-00';
6)使用startup force重启数据库(假设只丢了spfile,其他文件完好)
startup force
- 使用恢复目录
Rman会使用恢复目录找出最新的控制文件备份,因此不需使用autobackup参数。
1)启动RMAN
rman target sys/sys catalog rcat_manager/password@tnsname
2)在rman使用startup nomount启动数据库实例
startup nomount
3)提取数据库spfile(默认还原最新的文件)
Restore spfile;
4)使用startup force重启数据库(假设只丢了spfile,其他文件完好)
startup force
三、 还原控制文件
与还原参数文件类似。还原控制文件前,需要使用正确的spfile启动数据库实例。
- 使用rman自动控制文件备份+FRA
1)启动RMAN
rman target sys/sys catalog rcat_manager/password@tnsname
2)在rman使用startup nomount启动数据库实例
startup nomount
3)提取数据库控制文件
如果使用FRA,不需要像spfile还原中那样定义FRA位置和数据库名称
Restore controlfile from autobackup;
4)恢复并打开数据库
alter database mount;
5)还原及恢复数据文件(如果完好可略过)
Restore database;
Recover database;
如果是noarchivelog模式且有redo log丢失,需要添加noredo参数
Recover database noredo;
6)重启数据库
Alter database open resetlogs;
Startup force;
- 使用rman自动控制文件备份+非FRA
如果没有在FRA中存储控制文件自动备份,RMAN需要获得不同信息(控制文件自动备份存储位置和DBID)才能找到它们,原因在于未使用FRA的标准格式。
1)启动RMAN
rman target /
2)设置要还原的spfile所在数据库的DBID
Set DBID=1145089261;
3)启动数据库实例到nomount状态
startup nomount
4)定义控制文件自动备份位置和文件名格式
Set controlfile autobackup format for device type disk to '/u02/backup/%F';
5)提取数据库controlfile(默认还原最新的文件)
Restore controlfile from autobackup;
6)恢复并打开数据库
Alter database mount;
还原数据文件(如果完好可略过)
Recover database;
如果是noarchivelog模式且有redo log丢失,需要添加noredo参数
Recover database noredo;
7)重启数据库
Alter database open resetlogs;
Startup force;
- 在新控制文件中注册数据文件备份和归档备份
将与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已恢复)
- 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命令可修改数据库控制文件中数据文件的位置
优先顺序如下:
SET NEWNAME FOR DATAFILE and SET NEWNAME FOR TEMPFILE
SET NEWNAME FOR TABLESPACE
SET NEWNAME FOR DATABASE
当使用SET NEWNAME FOR DATAFILE/TEMPFILE的时候,可以使用下面的SQL生成所有的SET NEWNAME命令:
select'setnewnamefordatafile'''||name||
'''to''/'||
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';
-- 或者重命名特定表空间数据文件
-- 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';
Restore database;
Recover database;
Switch datafile all;
Alter database open;
- ARCHIVELOG模式
与非归档模式最大的区别在于归档日志的应用
1)故障点数据库恢复(完全恢复)
前提:任何未归档的redo日志必须是完好的,否则只能不完全恢复
例子:假设丢失了所有数据文件及控制文件,redo日志完好,使用FRA
启动RMAN
rman target /
启动数据库实例到nomount状态
startup nomount
提取数据库controlfile
restore controlfile from autobackup;
为还原分配要使用的信道(不需定义位置,因为这步已经设了)
Allocate channel c1 device type disk;
提取数据库controlfile(默认还原最新的文件)
Restore controlfile from autobackup;
启动到mount状态,还原数据库
Alter database mount;
-- 可以先设置好并行度等,比如配置并行度为2
configure device type disk parallelism 2;
Restore database;
--如果准备还原的数据文件已存在,rman不会再还原该文件
恢复并打开数据库
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)非活动日志文件组成员丢失
这是最简单的一种情况,使用以下命令重建成员即可(丢失的成员可在alert日志中看到)
Alter database add logfile member xxx;
2)活动日志文件组成员丢失
如果数据库未崩溃
--避免数据丢失
Alter system checkpoint;
--重建重做日志组成员
Alter database add logfile '/data/app/logfile/redo02b.log' reuse to group 2;
如果数据库已崩溃
启动数据库到mount状态然后重建日志组成员,或者将未丢失成员复制一份重命名为丢失成员文件,再正常启动数据库。
- 非活动联机重做日志组丢失
这也是相对简单的情况,具体分为以下两种情况:
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;
如果运气好,不需任何恢复可能也能打开数据库:
Startup mount
Alter database clear unarchived logfile '/data/app/logfile/redo02.log';
Alter database open;
如果幸运,数据库将正常打开
如果打不开,将处于糟糕的境地,需要执行数据库不完全恢复(见后文)
六、 恢复CDB&PDB
- 恢复根容器
如果正好丢失了与根容器相关的数据文件,整个数据库很可能宕机,最终你只能无奈地在数据库停机时恢复根容器。
恢复步骤(假设只有数据文件有问题):
Startup mount
Restore database root;
recover database root;
alter database open;
当然也可以选择以前面的方法恢复数据文件
- 恢复种子容器
如果种子容器丢失,仍能成功打开数据库,控制台及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
- 恢复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 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 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执行不完全恢复
不完全恢复也称为时间点恢复(Point-In-Time Recovery,PITR),会影响整个数据库。不能只对数据库的一部分执行不完全恢复,这会导致恢复的数据与数据库其他部分SCN号不同,必须将整个数据库还原到同一个时间点。
不完全恢复具有四种不同类型:
基于时间的恢复
基于SCN的恢复
基于更改的恢复
基于还原点的恢复
- 原理(步骤概要)
1)执行restore database指出还原时间点(定义时间/SCN/日志更改号/还原点),Rman根据指定的时间点,还原完成时间最接近的数据库备份
2)执行recover database指出恢复时间点(定义时间/SCN/日志更改号/还原点),Rman将应用所需的增量备份和归档日志,将数据库恢复到所需时间点
3)使用alter database open resetlogs命令打开数据库,不完全恢复始终需要resetlogs打开数据库。Oracle将清除redo日志,使数据库做好准备支持将要创建的数据库新化身。
化身代表给定数据库的逻辑生命周期。在创建数据库时启动第一个化身,当使用resetlogs命令打开数据库时,该化身终结。随后的每一个化身都以使用resetlogs命令打开数据库为界。
可查询v$database_incarnation视图查看每个化身
4)打开后尽快备份数据库
- 创建恢复点
恢复目标是恢复进程的终点,通常我们基于定义时间/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;
-
基于时间的恢复
上面的例子即是基于时间点的恢复。需要注意的是,这个时间点是一个近似值,数据库的实际还原的时间点基于SCN,时间偏差约为3分钟。 -
基于SCN的恢复
准确,但未必常用
Startup mount;
Restore database until SCN 10000;
Recover database until SCN 10000;
alter database open resetlogs;
- 基于更改的恢复
恢复到指定序列号的归档日志(不包括指定的日志序列,开区间)
Startup mount;
Restore database until sequence 100 thread 1; --不包括100号
Recover database until sequence 100 thread 1; --不包括100号
alter database open resetlogs;
- 基于还原点的恢复
1)创建还原点
Create restore point test_001;
-- 为避免还原点过时(最多维护2048个),可使用guarantee的还原点
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的不完全恢复
- 关于PDB的时间点恢复(PITR)
首先rman需要创建一个辅助数据库,为此,rman需要还原所需的数据文件来启动和打开辅助实例。
还原表空间时,将包括system、sysaux和undo表空间,这些是启动辅助实例所需的基本表空间。另外,也还原与pdb相关的表空间。
还原非CDB或整个CDB时,只需要为还原的数据库文件及执行还原所需的归档文件准备空间。而在PDB PITR中,需要准备数据库数据文件占用的所有空间以及创建辅助数据库需要的所有空间。这意味着,PDB PITR很可能需要大量空间。
- 限制和要求
1)在rman执行PDB PITR时,会创建一个辅助实例。这个辅助实例使用FRA存储将要创建的数据文件从而执行恢复。若未定义FRA,则在执行recover命令时,必须使用auxiliary destination定义要创建的文件位置。
2)将PDB还原到不同时间点也会影响在整个CDB上使用闪回数据库的能力。如果将PDB还原到不同的时间点,你只能将数据库从当前时间点闪回到该PDB还原时间点(可以有一些方法绕过该限制,后面会提及)。
3)PDB PITR仅要求关闭正在恢复的PDB,其余部分正常运行。
4)务必准备足够的磁盘空间,还要确保用于创建辅助实例文件的os目录拥有适当权限。
5)如果还原或恢复操作失败,务必在失败后完全清除辅助实例。
连接到辅助实例,执行drop database命令将其从系统中删除
清除与辅助实例相关的某些元数据设置
Dbms_backup_restore.manageAuxInstance('{automatic_instance_name}',1);
- 基于时间恢复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;
- 基于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;
}
- 基于更改恢复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;
}
- 基于还原点恢复PDB
– 创建还原点
Create restore point test_001;
– 还原步骤
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;
九、 其他主题
- 只读表空间恢复
默认情况下,即使丢失只读数据文件,rman也不会在执行完整数据库还原操作时还原只读数据文件,需要额外指定参数:
Restore database check readonly;
--或
Restore database check force;
执行recover tablespace或recover datafile时,不论是否只读文件都会进行恢复
- 归档重做日志的还原
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;
}
- 数据文件副本还原
Restore (datafile 5) from datafilecopy;
Restore datafile 5;
Sql "alter database datafile 5 online;"
- 恢复受损数据块
如果遇到报错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;
修复后再次执行backup validate database;检测,确保已不存在其他受损块
- 恢复到前一个化身
1)奇怪的还原需求:
需要使用上次执行resetlogs命令打开数据库前的一个备份来还原数据库,或者可能需要还原到执行上一个resetlogs命令之前的时间点。
2)准备还原
要还原到前一个化身,需要了解要还原的化身,了解可使用哪些还原:
List incarnation of database;
如果尝试还原到早于当前数据库化身的时间点,通常会遇到报错
RMAN-20208: UNTIL CHANGE is before RESETLOGS change
要执行此还原,需要告知RMAN你真正要恢复到的化身。
3)执行还原
启动数据库到nomount状态
Startup nomount
还原与要还原的化身相关的控制文件
Run
{
Set until time "to_date('2019-01-07 06:15:07','yyyy-mm-dd hh24:mi:ss')";
Restore controlfile from autobackup;
}
重置数据库化身
Alter database mount;
Reset database to incarnation 2;
基于需要的还原时间执行还原和恢复
Run
{
Set until scn 3318383;
Restore database force;
Recover database;
}
打开数据库
Alter database open resetlogs;
十、 表和分区时间点恢复
12c中引入了新特性,支持单独数据库表和单独表分区的时间点还原。
- 前提条件
源库处于Archivelog模式
要恢复单独分区,必须将compatible参数设置为11.1.0或更高
必须拥有SYSTEM,SYSAUX,UNDO表空间的rman备份
包含要还原对象的表空间的备份必须是可用的
必须拥有从用于恢复对象的备份开始-尝试还原的时间点之间的所有归档日志
目标数据库(用于还原表或分区的数据库)必须以只读模式打开
目标数据库也必须处于archivelog模式 - 限制
不能还原属于sys模式的表
不能还原存储于system和sysaux表空间中的表
不能还原备用数据库中的表分区
不能在备用数据库执行这些还原
如果表有not null约束,则不能使用remap选项将表还原为不同名称 - 还原原理
首先执行restore命令,rman首先创建辅助数据库,然后从物理备份将所有需要的表空间还原到该数据库。Rman仅还原system,sysaux,undo和sysext表空间(如果存在),以及包含要还原的特定对象的表空间。
Rman还原辅助数据库后,将数据库前滚到在restore命令中指定的时间点,接着dump待还原对象。dump后,可以由rman也可以自行导入目标数据库。完成操作后,rman将清理辅助数据库。
- 举例
1)启动还原前,需要确定在何处保存与辅助数据库相关的文件,还需要确定对象是用回以前的名字还是新名字
2)确定以后,执行以下命令(非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;
3)如果从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)确定还原的时间点
若未使用恢复目录,表空间的恢复是一次性过程(如果选错了时间点,不能重新尝试恢复),使用恢复目录则无此限制。
2)确保传送集中的对象是独立的
使用TS_PITR_CHECK视图确认恢复集是完整的,并标识所有要用到的其他表空间。
– 检查表空间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)保存可能在恢复过程中丢失的数据
TS_PITR_OBJECTS_TO_BE_DROPPED视图可以列出将在恢复操作期间丢失的所有对象。
Select * from TS_PITR_OBJECTS_TO_BE_DROPPED where tablespace_name='TEST_RECOVER';
实际执行
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;
注意事项:
可选参数auxiliary destination指示rman在何处创建与辅助数据库关联的文件。若使用该参数,该恢复称为具有自动化实例的自定义TSPITR;若不使用,则称为完全自动的TSPITR
auxiliary destination指示的目录应该已存在并且Oracle能够写入,另外目录路径最后一定不要有斜杠,否则TSPITR会失败且错误描述难以判断
3. 清理辅助实例
Exec dbms_backup_restore.manageauxinstance('辅助实例SID'),1);
参考
https://docs.oracle.com/database/121/BRADV/rcmadvre.htm#BRADV008
《Oracle Database 12c Oracle RMAN备份与恢复》