13518219792
这篇文章主要介绍“如何使用RMAN还原和恢复数据库”，在日常操作中，相信很多人在如何使用RMAN还原和恢复数据库问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何使用RMAN还原和恢复数据库”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
成都创新互联专注于网站建设|网页维护|优化|托管以及网络推广，积累了大量的网站设计与制作经验，为许多企业提供了网站定制设计服务，案例作品覆盖岗亭等行业。能根据企业所处的行业与销售的产品，结合品牌形象的塑造，量身策划品质网站。
一、数据恢复顾问DRA的使用
数据恢复顾问（Data Recovery Advisor，DRA）是Oracle 11g中新增的一个诊断和修复数据库问题的工具。共有两种界面：RMAN可执行程序界面和企业管理器Enterprise Manager界面。DRA能够生成脚本来修复数据文件和（在某些环境下）控制文件受到的损坏。它不提供有关服务器参数文件和联机日志文件问题的建议。DRA的决策依赖于自动诊断知识库（Automatic Diagnostic Repository，ADR）和健康检查Health Monitor。
Health Monitor是一组检查，检查结果不存储在数据库，而存储在文件系统中。其原因在于，一些错误的性质决定了数据库不再可用，因此需要一个外部知识库来存储Health Monitor的结果。这个知识库就是自动诊断知识库（ADR），位于diagnostic_dest实例参数指定的目录中。
show parameter diagnostic_dest;
NAME TYPE VALUE
------------------------------------ ----------- ------------
diagnostic_dest string C:\ORACLE
可以看到其默认是在Oracle安装的基目录中，有个diag子目录就是存放ADR的位置。
健康检查Health Monitor在数据库不同的模式阶段将运行不同的检查内容：
在nomount模式下，只能检查控制文件的完整性，因为数据库还没有装载；
在mount模式下，将检查控制文件、联机重做日志文件和数据文件头部的完整性，也将检查归档日志文件的完整性；
在open模式下，将可扫描每个数据文件块是否受损，并检查数据字典和撤销段的完整性。
DRA的功能有一定的局限性。例如，只有当实例处于nomount或更高模式时，DRA才能奏效。如果初始化文件存在问题，它就起不到帮助作用。但一旦能进入nomount模式，它就可以诊断控制文件的问题，并使用现有的有效副本（如果不存在，就尝试从备份集中提取一个副本）生成用来还原的脚本。再一旦数据库进入mount模式，DRA就可以诊断有关数据文件缺失或受损的问题，以及联机日志文件组丢失的问题，并生成修复脚本。DRA只能用于单实例数据库的环境，不能用于RAC集群环境，也不能用于Data Guard备用数据库。如果RAC数据库故障，可以在单实例模式中加载，使用DRA修复损坏的内容，然后关闭它并在RAC模式中重新打开。
数据恢复顾问DRA的使用非常简单，RMAN环境下包括以下三个步骤：
1）使用list failure命令列出故障；
2）使用advise failure命令给出故障处理建议；
3）使用repair failure命令修复故障。
数据恢复顾问DRA使用健康检查Health Monitor收集的信息查找问题并构建RMAN脚本进行修复。如果不首先要求DRA列出故障，则DRA不会生成建议。对于最后一次列出之后再发生的故障，DRA不提供任何建议。
以下通过一个例子，说明数据恢复顾问（DRA）的使用。
1）在操作系统提示符下进入RMAN程序
C:\Users\Administrator>rman target /
恢复管理器: Release 11.2.0.4.0 - Production on 星期四 5月 3 10:33:33 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
已连接到目标数据库: MES (DBID=2056489697)
2）确认已存在SYSAUX表空间的完整备份
RMAN> list backup of tablespace sysaux;
使用目标数据库控制文件替代恢复目录
备份集列表
===================
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ -------------------
241 Incr 0 312.86M DISK 00:01:00 2018-05-03 10:31:49
BP 关键字: 241 状态: AVAILABLE 已压缩: YES 标记: TAG20180503T103048
段名:E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503
备份集 241 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ------------------- ----
2 0 Incr 1640735 2018-05-03 10:30:49 D:\ORADATA\MES\SYSAUX01.DBF
如果没有备份就创建一个
RMAN> backup as backupset tablespace sysaux;
3）关闭实例并退出
RMAN> shutdown immediate;
RMAN> exit;
4）利用操作系统程序删除sysaux表空间的数据文件
5）使用SQL*Plus连接到数据库，并尝试启动
C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on 星期四 5月 3 10:42:42 2018
Copyright (c) 1982, 2013, Oracle. All rights reserved.
已连接到空闲例程。
10:42:42 SYS @ mes AS SYSDBA>startup
ORACLE 例程已经启动。
Total System Global Area 1286066176 bytes
Fixed Size 2280896 bytes
Variable Size 771752512 bytes
Database Buffers 503316480 bytes
Redo Buffers 8716288 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 2 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 2: 'D:\ORADATA\MES\SYSAUX01.DBF'
启动时提示sysaux01.dbf文件缺失，并停留在mount加载模式。
6）再次启动RMAN并诊断问题
C:\Users\Administrator>rman target /
恢复管理器: Release 11.2.0.4.0 - Production on 星期四 5月 3 10:44:17 2018
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
已连接到目标数据库: MES (DBID=2056489697, 未打开)
RMAN> list failure;
使用目标数据库控制文件替代恢复目录
数据库故障列表
=========================
失败 ID 优先级状态 检测时间 概要
------- -------- --------- ------------------- -------
4932 HIGH OPEN 2018-05-02 23:01:58 缺失一个或多个非系统数据文件
4908 HIGH OPEN 2018-05-02 23:01:58 一个或多个非系统数据文件需要介质恢复
返回一条消息，提示一个非系统数据文件的缺失。
7）生成有关故障的建议
RMAN> advise failure;
数据库故障列表
=========================
失败 ID 优先级状态 检测时间 概要
------- -------- --------- ------------------- -------
4932 HIGH OPEN 2018-05-02 23:01:58 缺失一个或多个非系统数据文件
4908 HIGH OPEN 2018-05-02 23:01:58 一个或多个非系统数据文件需要介质恢复
正在分析自动修复选项; 这可能需要一些时间
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=221 设备类型=DISK
分析自动修复选项完成
必需的手动操作
========================
没有可用的手动操作
可选手动操作
=======================
1. 如果无意中重命名或移动了文件 D:\ORADATA\MES\SYSAUX01.DBF, 请还原该文件
2. 如果还原了错误版本的数据文件 D:\ORADATA\MES\SYSAUX01.DBF, 请使用正确版本将其替换
自动修复选项
========================
选项修复说明
------ ------------------
1 还原和恢复数据文件 2
策略: 修复操作包括无数据丢失的完全介质恢复
修复脚本: C:\ORACLE\diag\rdbms\mes\mes\hm\reco_339425269.hm
8）打开修复脚本，研究其内容，可以看到包括以下修复语句
restore datafile 2;
recover datafile 2;
sql 'alter database datafile 2 online';
10）要运行脚本，可使用以下命令
RMAN> repair failure;
策略: 修复操作包括无数据丢失的完全介质恢复
修复脚本: C:\ORACLE\diag\rdbms\mes\mes\hm\reco_339425269.hm
修复脚本的内容:
# restore and recover datafile
restore datafile 2;
recover datafile 2;
sql 'alter database datafile 2 online';
是否确实要执行以上修复 (输入 YES 或 NO)? y
执行修复脚本
启动 restore 于 2018-05-03 10:50:36
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00002 还原到 D:\ORADATA\MES\SYSAUX01.DBF
通道 ORA_DISK_1: 正在读取备份片段 E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503
通道 ORA_DISK_1: 段句柄 = E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503 标记 = TAG20180503T103048
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:35
完成 restore 于 2018-05-03 10:51:12
启动 recover 于 2018-05-03 10:51:12
使用通道 ORA_DISK_1
正在开始介质的恢复
介质恢复完成, 用时: 00:00:01
完成 recover 于 2018-05-03 10:51:13
sql 语句: alter database datafile 2 online
修复故障已完成
是否要打开数据库 (输入 YES 或 NO)? y
数据库已打开
以上看到，系统自动定位最新的备份文件，经过数据还原和介质恢复，完成后提示打开数据库。
二、数据文件丢失后的完整恢复
在Oracle数据库中，有些文件是关键的（critical），关键文件受损意味着数据库实例将终止，在损坏被修复之前不能重新打开。有些文件是非关键的（noncritical），如果这些文件受损，数据库仍能保持打开或可以被打开。
构成SYSTEM表空间和当前活动的撤销表空间（由undo_tablespace参数指定）的数据文件被认为是关键的，控制文件的任何副本也都是关键的，这类文件受损将导致实例终止运行。构成用户数据表空间的文件则是非关键的，这些文件受损通常不会导致实例崩溃。使受损的文件脱机，使其内容不可访问，可使数据库的其余部分仍可保持打开。
通常，任意数目的数据文件的损坏都可用完整恢复来修复，不会有数据丢失。还原受损的文件，再应用重做使它们保持最新。当然，前提条件是自数据文件上一次备份后生成的所有归档日志文件可用。不完整恢复意味着还原数据库并只应用重做至某个特定点，在该点之后所做的所有工作将丢失。为什么要不完整恢复？通常只有一个原因：用户错误。如果因为用户操作错误，则需要将整个数据库返回到错误发生之前。不完整恢复的第二种原因是尝试了完整恢复，但失败了。这会在归档日志文件缺失或当前联机日志文件组的所有副本丢失的情况下发生。
1、非归档日志模式下的数据文件恢复
在非归档日志模式下，没有什么支持恢复的技术，因为恢复所需的归档日志并不存在，因此只能进行还原，但这样也丢失了自备份创建之后所做的所有工作。
还原过程只能在加载模式下运行
shutdown abort;
startup mount;
restore database;
recover database;
alter database open resetlogs;
2、归档日志模式下丢失非关键文件时的恢复
归档模式下，如果损坏的是非关键数据文件，则还原和恢复过程包括以下四步：
1）使受损的数据文件脱机（可能系统已自动完整），如果还没有脱机，则可执行以下命令，如指定10#文件脱机
RMAN> sql'alter database datafile 10 offline';
受损文件脱机后，数据库应该已经可以打开。
2）还原数据文件
RMAN> restore datafile 10;
3）恢复数据文件
RMAN> recover datafile 10;
4）使数据文件联机
RMAN> sql'alter database datafile 10 online';
以上命令中有的属于SQL命令而非RMAN命令，因此在RMAN环境下执行时，需要添加sql前缀。
如果备份时使用的是增量备份策略，还原和恢复操作将首先利用级别0备份，然后应用级别1备份，最后再应用重做数据完成恢复。这一方法（使对重做的使用最小化）背后的逻辑是应用增量备份总是比应用重做要快。增量备份存在与否并不会导致使用recover命令时的语法差别，RMAN通过询问其存储库，将计算出执行操作的最好方法。
3、丢失关键数据文件时的恢复
如果数据库因为关键数据文件损坏而崩溃，那么第一行动就是试着启动它。这将在加载模式下停止，同时将错误消息写入警报日志。要进行恢复，可以采取和非关键文件一样的过程，只是还原和恢复只能在加载模式下进行，因为数据库已不能打开。例如要还原3#文件，此时还原和恢复包括以下四步：
1）数据库启动到加载模式
RMAN> startup mount;
2）还原数据文件
RMAN> restore datafile 3;
3）恢复数据文件
RMAN> recover datafile 3;
4）打开数据库
RMAN> alter database open;
三、数据文件丢失后的不完整恢复
执行不完整恢复只有两个原因：完整恢复不可行或是故意要丢失数据。如果缺失归档日志或当前联机重做日志文件组的所有副本缺失，那么必须执行不完整恢复。对于用户错误，可以还原整个数据库并将它恢复至错误发生前的点，但也同时失去了自那之后所做的所有正确的工作。
不完整恢复的特例是控制文件的恢复。在理想情况下，所有恢复操作将使用当前控制文件来引导，但有时是不可能的，必须还原控制文件的备份。可能的原因有两点：1）当前控制文件的所有副本已丢失，不能运行create controlfile命令重新创建它们。
2）当前控制文件已不能准确描述想要还原的数据库版本，如表空间和数据文件的结构在最近一次备份后已发生了更改。这个时候还原数据文件的同时必须首先还原控制文件。
不完整恢复分为四个步骤：
1）加载数据库
2）还原所有数据文件
3）恢复数据库至某个点（以下会说明包括三种指定方式）
4）用重置日志打开数据库
与完整恢复相比，不完整恢复有以下几点不同：
1）开始时，完整恢复可在数据库打开时进行，除非受损文件是关键的，而不完整恢复只能在加载模式下进行。
2）还原时，对于完整恢复，只需还原受损的数据文件，而不完整恢复需要还原所有数据文件，必须还原到早于想恢复的点。
3）恢复时，需要将归档日志和联机日志的重做数据应用到所需的点，有几个选项可用于指定想恢复到的点。
4）打开时，需要用RESETLOGS打开数据库，这将重新初始化联机重做日志文件，创建数据库的一个新化身。数据库的化身是指带有新的重做线程（日志序列号从1开始）的数据库版本。备份和归档日志都是特定于一个化身的，由不同化身生成的备份和归档日志逻辑上是彼此分离的，不能互用。正因如此，当使用RESETLOGS重置日志文件后，应当立即重新执行一次完整的数据库备份。
加载数据库并还原所有数据文件（必要时还包括还原控制文件）后，对于不完整恢复操作有三种选项：
1）UNTIL TIME
该选项将应用重做前滚数据文件至一个特定时间，精度为秒。该选项通常用于纠正用户错误，如果用户犯了不可逆的错误，但知道犯错误的时间，那么就可以基于时间恢复至错误发生之前。
2、UNTIL SCN
如果已知错误发生时的确切的系统改变号SCN，那么可使用该选项准确的将恢复停在错误发生之前，从而尽可能少的丢失数据。这需要使用如Log Miner这样的高级工具或是使用闪回功能，确定提交事务时的SCN。
3、UNTIL SEQUENCE
如果归档日志文件或联机日志文件组缺失，则使用该选项，它会将恢复工作停止至指定的归档日志序列号。
默认情况下，RMAN应按最近的备份来还原，并应用重做。但不完整恢复与此不同，必须从早于恢复点的备份进行还原，再前滚到那个需要恢复到的时间点。要确保还原和恢复使用相同的UNTIL TIME，最佳办法是在一个run块中完成还原和恢复这两个命令。
RMAN> run {
startup mount;
set until time = "to_date('2015-11-01 10:00:00', 'yyyy-mm-dd hh34:mi:ss')";
restore database;
recover database;
alter database open resetlogs;
}
命令set until time指定一个将应用到所有后续命令的时间，最终数据库将还原和恢复到该时间点的状态上。当然也可以单独指定UNTIL值
RMAN> restore database until time 'sysdate -7';
RMAN> recover database until time '27-OCT-08';
这里如果没有像前面run块那样指定时间格式，那么时间识别依赖于初始化参数NLS_DATE_FORMAT，如上命令假设NLS_DATE_FORMAT被设置为dd-MON-rr。
四、控制文件的自动备份和恢复
数据库严重依赖于控制文件，如果控制文件受损，数据库将崩溃。RMAN的情况更糟，存放备份信息的RMAN存储库就存储在控制文件中。因此，如果控制文件损坏，一方面数据库将崩溃，而另一方面RMAN又不能恢复它，因为RMAN所需要的信息不可用。这是个递归性的问题，解决这一问题的办法是使用RMAN目录数据库或者启用控制文件的自动备份功能。
要启用控制文件的自动备份，在RMAN提示符下执行以下命令
RMAN>CONFIGURE CONTROLFILE AUTOBACKUP ON;
该命令执行后，每个RMAN操作都会把控制文件和spfile文件自动备份到已知位置的备份集中。指定好自动备份的路径，未指定时默认保存在闪回恢复区，文件名基于DBID。数据库的ID是一个10位数字。DBID在启动RMAN时可以看到，也可以通过查询视图v$database的字段DBID获知。以下设定控制文件自动备份的保存路径
RMAN>CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'e:\rman_bak\mes\control_bak\%F';
若要还原控制文件，可在数据库处于非加载模式下执行以下命令
RMAN> restore controlfile from autobackup;
该命令从最近的自动备份中提取控制文件，还原到spfile初始化参数文件指定的位置。之后便可用还原的控制文件加载数据库，RMAN将可以定位所需的备份来还原数据库的其余部分。由于非加载模式下控制文件尚未加载，RMAN不知道自动备份控制文件的位置，故会从默认位置还原控制文件（包含spfile），该位置对于Windows来说是%ORACLE_HOME%\database，对于Unix系统来说是$ORACLE_HOME\dbs。因此还原前应当首先把最近一次自动备份的控制文件（包含spfile）复制到该路径下。
如果spfile文件也丢失了，则可用哑初始化参数文件启动实例：只有一个参数db_name的pfile文件（如内容只有一行db_name=mes）。然后用RMAN连接，发出以下命令替换为自己的DBID
RMAN> set dbid1979336967;
RMAN> restore spfile from autobackup;
该命令将spfile文件还原到系统默认位置（Windows是%ORACLE_HOME%\database，Unix是$ORACLE_HOME\dbs）。之后再以非加载模式重启实例，便可进行控制文件的还原以及后续数据库的还原。
数据库的ID号一般可以从备份的控制文件名上获得，如控制文件备份C-1979336967-20151116-00，1979336967即是DBID。在RMAN连接到目标数据库时也会提示DBID。视图v$database中也包含了DBID字段的信息。
RMAN也只有这两个关于spfile文件和控制文件的还原命令能在非加载模式下执行，所有其他命令只能在加载模式或打开模式下执行。
下列脚本用哑初始化参数文件dummy.ora开始实例的启动，逐步完成数据库的完整还原和恢复（假定所有数据文件、控制文件、spfile文件都已丢失）
run {
startup nomount pfile = C:\oracle\product\11.2.0\dbhome_1\database\dummy.ora;
set dbid = 1979336967;
restore spfile from autobackup;
shutdown abort;
startup nomount;
restore controlfile from autobackup;
alter database mount;
restore database;
recover database;
alter database open resetlogs;
}
如果之前没有启用控制文件的自动备份，但有包含spfile和controlfile的备份集，则命令可以指定包含该内容的备份
restore spfile from 'e:\rman_bak\mes\control_bak\C-2056489697-20180502-06';
五、不完整恢复实验
1、实验前备份的构建
更改控制文件的备份配置，设为自动备份，并指定备份的目标路径
RMAN> configurecontrolfileautobackupon;
RMAN> configurecontrolfileautobackupformatfordevicetypediskto 'e:\rman_bak\mes\control_bak\%F';
更改数据文件备份集的目标位置和命名规则
RMAN> configurechanneldevicetypediskformat 'e:\rman_bak\mes\%d_%u_%c_%T';
执行一次完整的数据库增量级别1压缩备份，并将之前（已不再需要）的归档日志文件删除
RMAN> backup incremental level 1 as compressed backupset database plus archivelog delete all input;
2、清楚需要恢复的时间点
当故障发生后，我们需要将系统恢复到故障发生之前的某一时刻，这个时间愈靠近故障发生时刻，就愈能保证恢复后不丢失用户数据，因此在实验前我们先明确一下当前时间。
select sysdate from dual;
SYSDATE
-------------------
2018-05-03 12:09:34
3、故障模拟
假定现在由于用户误操作，不小心删除了CMES表空间，导致重要数据丢失
drop tablespacecmes including contents and datafiles;
4、还原控制文件
由于表空间的删除，数据库的结构发生了变化，该变化已被记入当前的控制文件。因此如果要恢复到故障之前的状态，必须首先恢复未删除表空间之前的控制文件，用原有的控制文件加载数据库，之后再还原表空间和数据文件。
登录RMAN，构建一个run块，设置还原时间点，然后还原控制文件到一个指定的路径
RMAN> run {
2> shutdown abort;
3> startup mount;
4> set until time = '2018-05-03 12:09:34';
5> restore controlfile to 'D:\control.ctl';
6> }
Oracle 实例已关闭
已连接到目标数据库 (未启动)
Oracle 实例已启动
数据库已装载
系统全局区域总计 1286066176 字节
Fixed Size 2280896 字节
Variable Size 771752512 字节
Database Buffers 503316480 字节
Redo Buffers 8716288 字节
正在执行命令: SET until clause
启动 restore 于 2018-05-03 12:18:35
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=189 设备类型=DISK
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在还原控制文件
输出文件名=D:\CONTROL.CTL
通道 ORA_DISK_1: 正在读取备份片段 E:\RMAN_BAK\MES\CONTROL_BAK\C-2056489697-20180503-02
通道 ORA_DISK_1: 段句柄 = E:\RMAN_BAK\MES\CONTROL_BAK\C-2056489697-20180503-02 标记 = TAG20180503T105757
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:01
完成 restore 于 2018-05-03 12:18:37
5、用还原出来的控制文件重新加载数据库
alter system set control_files = 'D:\control.ctl' scope = spfile;
shutdown abort
startup mount
6、按设定的时间点进行数据库的还原和恢复
在RMAN会话中构建以下run块，设置还原和恢复的时间点，然后进行数据库的还原和恢复，并打开数据库
RMAN> run {
allocate channel c1 type disk;
allocate channel c2 type disk;
set until time = '2018-05-03 12:09:34';
restore database;
recover database;
alter database open resetlogs;
}
使用目标数据库控制文件替代恢复目录
分配的通道: c1
通道 c1: SID=221 设备类型=DISK
分配的通道: c2
通道 c2: SID=3 设备类型=DISK
正在执行命令: SET until clause
启动 restore 于 2018-05-03 12:25:41
启动 implicit crosscheck backup 于 2018-05-03 12:25:41
已交叉检验的 5 对象
完成 implicit crosscheck backup 于 2018-05-03 12:25:41
启动 implicit crosscheck copy 于 2018-05-03 12:25:41
完成 implicit crosscheck copy 于 2018-05-03 12:25:42
搜索恢复区中的所有文件
正在编制文件目录...
没有为文件编制目录
通道 c1: 正在开始还原数据文件备份集
通道 c1: 正在指定从备份集还原的数据文件
通道 c1: 将数据文件 00001 还原到 D:\ORADATA\MES\SYSTEM01.DBF
通道 c1: 将数据文件 00002 还原到 D:\ORADATA\MES\SYSAUX01.DBF
通道 c1: 将数据文件 00003 还原到 D:\ORADATA\MES\UNDOTBS01.DBF
通道 c1: 将数据文件 00004 还原到 D:\ORADATA\MES\USERS01.DBF
通道 c1: 将数据文件 00005 还原到 D:\ORADATA\MES\EXAMPLE01.DBF
通道 c1: 正在读取备份片段 E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503
通道 c2: 正在开始还原数据文件备份集
通道 c2: 正在指定从备份集还原的数据文件
通道 c2: 将数据文件 00006 还原到 D:\ORADATA\MES\CMES01.DBF
通道 c2: 将数据文件 00007 还原到 D:\ORADATA\MES\RMES01.DBF
通道 c2: 将数据文件 00008 还原到 D:\ORADATA\MES\HMES01.DBF
通道 c2: 将数据文件 00009 还原到 D:\ORADATA\MES\INDX01.DBF
通道 c2: 将数据文件 00010 还原到 D:\ORADATA\MES\FDA01.DBF
通道 c2: 正在读取备份片段 E:\RMAN_BAK\MES\MES_86T1V58Q_1_20180503
通道 c2: 段句柄 = E:\RMAN_BAK\MES\MES_86T1V58Q_1_20180503 标记 = TAG20180503T103048
通道 c2: 已还原备份片段 1
通道 c2: 还原完成, 用时: 00:00:15
通道 c1: 段句柄 = E:\RMAN_BAK\MES\MES_85T1V56P_1_20180503 标记 = TAG20180503T103048
通道 c1: 已还原备份片段 1
通道 c1: 还原完成, 用时: 00:00:46
完成 restore 于 2018-05-03 12:26:30
启动 recover 于 2018-05-03 12:26:30
正在开始介质的恢复
线程 1 序列 7 的归档日志已作为文件 D:\ORADATA\MES\REDO01.LOG 存在于磁盘上
线程 1 序列 8 的归档日志已作为文件 D:\ORADATA\MES\REDO02.LOG 存在于磁盘上
归档日志文件名=D:\ORADATA\MES\REDO01.LOG 线程=1 序列=7
归档日志文件名=D:\ORADATA\MES\REDO02.LOG 线程=1 序列=8
介质恢复完成, 用时: 00:00:03
完成 recover 于 2018-05-03 12:26:36
数据库已打开
释放的通道: c1
释放的通道: c2
7、恢复控制文件的复用状态
数据库打开后，查看当前启用的控制文件
show parameter control_files;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string D:\CONTROL.CTL
修改控制文件参数，回到原先的多路复用状态
alter system set control_files='d:\oradata\mes\control01.ctl','e:\fast_recovery_area\mes\control02.ctl' scope=spfile;
关闭数据库
shutdown immediate
将控制文件d:\control.ctl分别复制到d:\oradata\mes\control01.ctl和e:\fast_recovery_area\mes\control02.ctl中
重启数据库
startup
数据库打开后再次确认启用的控制文件
show parameter control_files;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string D:\ORADATA\MES\CONTROL01.CTL,
E:\FAST_RECOVERY_AREA\MES\CONT
ROL02.CTL
由于恢复使用RESETLOGS重置了联机日志文件（日志序列号重新从1开始），因此创建的是数据库的一个新化身，之前的备份和归档日志已经和当前数据库分离，因此可以在RMAN下将之前的备份和归档日志删除，并尽快重新执行一次完整的数据库备份。
六、使用映像副本恢复
如果备份策略包括映像副本，那么另一种还原选择实际就是根本不用还原。由于映像副本与原数据文件是完全相同的，因此如果磁盘上有，则可以立即使用它。需要做的就是告诉数据库映像副本的位置，然后恢复副本。与从备份集中提取数据文件所引起的延迟相比，映像副本的恢复可节省大量时间。
可使用下列RMAN命令创建整个数据库的映像副本
RMAN> backup as copy database;
如果没有更改默认的备份位置参数，那么该命令将所有数据文件复制到闪回恢复区作为映像副本。要使用映像副本，首先使原数据文件脱机（可能已经自动发生），然后更新控制文件中数据文件的指向，再恢复副本文件。例如有如下创建的副本
RMAN> backup as copy datafile 5 format 'e:\rman_bak\mes\cmes01.dbf';
通过以下脚本可以使用它
RMAN> run {
sql'alter database datafile 5 offline';
set newname for datafile 5 to 'e:\rman_bak\mes\cmes01.dbf';
switch datafile 5;
recover datafile 5;
sql'alter database datafile 5 online';
}
如果已对整个数据库创建了映像副本，则可用一条命令还原整个数据库
RMAN> switch database to copy;
映像副本的另一种使用方法是通过增量备份来更新副本，以维护副本的较新状态。这要求将数据库的完整副本作为起点，之后创建增量备份，将其应用至副本中。以下开辟两个通道并行备份，将副本更新到闪回恢复区中，文件名格式将是OMF的
RMAN> run {
allocate channel c1 type disk;
allocate channel c2 type disk;
backup incremental level 1 for recover of copy with tag 'inc_copy' database;
recover copy of database with tag 'inc_copy';
release channel c1;
release channel c2;
}
该命令首次运行时，RMAN尝试增量级别1备份，但由于之前没有级别0备份，因此执行级别0备份。该语句生成一个映像副本。recover命令在首次执行时将失败，因为没有可用的副本和增量备份。脚本第二次运行时，第一个命令将执行增量级别1备份，提取自上一次备份后所有的变更块，第二个命令则把这个增量变更应用到副本。以后每次运行都延续该行为。这种基于增量更新副本的策略可以使恢复过程非常快。
到此，关于“如何使用RMAN还原和恢复数据库”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
