oracle--20数据库恢复与备份2

备份是数据的一个代表性副本。该副本会包含数据库的重要部分，如控制文件、重做日志和数据文件。
备份通过提供一种还原原始数据的方法保护数据不受应用程序错误的影响并防止数据的意外丢失。
备份分为物理备份和逻备份。物理备份是物理数据库文件的副本。“备份与恢复”通常指将复制的文件从一个位置转移到另一个位置，同时对这些文件执行各种操作。
相比而言，逻辑备份包含使用SQL 命令导出并存储在二进制文件中的数据。Oracle 在重做日志缓冲区中记录提交的和未提交的更改。
逻辑备份用于补充物理备份。还原物理备份意味着重建它并将其提供给Oracle 服务器。要恢复还原的备份，需要使用事务日志中的重做记录来更新数据。事务日志记录在执行备份之后对数据库所做的更改。
Oracle 在例程故障之后自动执行崩溃恢复和实例恢复。在出现介质故障的情况下，数据库管理员(DBA) 必须启动恢复操作。
恢复备份涉及两种不同的操作：通过应用重做数据将备份前滚至一个较近的时间；将在未提交的事务中所做的所有更改回滚至其原来状态。
一般而言，恢复指在还原、前滚和回滚备份中涉及的各种操作。备份与恢复指在防止数据库丢失数据和在丢失数据时重建数据库的过程中涉及的各种策略和操作。
备份是数据文件、表空间或某个时间点的数据库等的快照。如果对数据库进行了周期性备份，则在数据丢失时用户可以将存储的重做信息应用到他们最新的备份中，从而恢复数据库的当前状态。
Oracle 使用户能够还原一个较早的备份和仅应用某些重做数据，从而将数据库恢复到一个较早的时间点。这种恢复称为不完全介质恢复。如果备份是一致的，那么根本不需要用户应用任何重做数据。


++++++++++++++++++++++++++++++++++
归档设置

归档的作用
归档的作用是在出现故障时可以恢复数据
归档日志其实是重做日志的复本，通过ARCn归档进程复制重做日志文件而生成
归档只有在数据库被配置为“归档模式”时才会被启用

Oracle通过Redo来保证数据库的事务可以被重演，从而使得在故障之后，数据可以被恢复。Redo对于Oracle数据库来说至关重要。
在数据库中，Redo的功能主要通过3个组件来实现：Redo Log Buffer、LGWR后台进程和Redo Log File（在归档模式下，Redo Log File最终会写出为归档日志文件）。

Redo Entries的内容被Oracle数据库进程从用户的内存空间复制到SGA中的Redo Log Buffer之中。
Redo Entries在内存中占用连续的顺序空间，由于Redo Log Buffer是循环使用的，Oracle通过一个后台进程LGWR不断地把Redo Log Buffer的内容写出到Redo Log File中。
当用户在Buffer Cache中修改数据时，Oracle并不会立即将修改数据写出到数据文件上,因为那样做效率会很低，
到目前为止，计算机系统中最繁忙的部分是磁盘的I/O操作，Oracle这样做的目的是为了减少IO的次数，当修改过的数据达到一定数量之后，可以进行高效地批量写出。

同Redo Log Buffer类似，Redo Log File也是循环使用的，Oracle允许使用最少两个日志组。缺省情况下，数据库创建时会建立3个日志组。
SQL> select group#,members,status from v$log;
当一个日志文件写满之后，会切换到另外一个日志文件，这个切换过程称为Log Switch。Log Switch会触发一个检查点，促使DBWR进程将写满的日志文件保护的变更数据写回到数据库。
在检查点完成之前，日志文件是不能够被重用的。
在检查点完成之后，此检查点之前修改过的数据都已经写回磁盘，重做日志文件中的相应重做记录对于崩溃/实例恢复不再有用。
如果此后数据库崩溃，那么恢复只需要从最后一次完成的检查点开始恢复即可。如果数据库运行在归档模式（所有生产数据库，都建议运行在归档模式），
日志文件在重用之前必须写出到归档日志文件，归档日志在介质恢复时可以用来恢复数据库故障。
如果数据库配置为NOARCHIVELOG 模式，则没有重做历史记录保存到归档日志文件
中，恢复操作将受到限制，并且可能会导致事务处理工作丢失。这是日志文件自动循环的结果，在该循环过程中，恢复操作所需的较旧的日志文件被覆盖，只有该事务历史记录的最新部分可用。
可以以将数据库配置为ARCHIVELOG 模式，以便重做信息的历史记录可以保留在归档文件中。归档重做日志文件可以用于介质恢复。
数据库最初可以在ARCHIVELOG 模式下创建，但缺省情况下配置为NOARCHIVELOG模式。

归档模式的设置与取消
将数据库设置为ARCHIVELOG 模式的含义：
出现介质故障时，可以防止数据库丢失数据。可以在数据库联机时对其进行备份。由于介质故障导致表空间（非SYSTEM）脱机时，数据库的其余部分仍可用，因为表空间（非SYSTEM）可以在数据库打开时恢复。
介质恢复选项：
无论数据库处于联机或脱机状态，您都可以还原损坏文件的备份副本，并使用归档日志文件将数据文件更新为当前的版本。
可以将数据库恢复至特定的时间点。可以将数据库恢复至指定归档日志文件的末尾。可以将数据库恢复至特定的系统更改号(SCN)。

查看所当前连接的数据库，如下所示：
SQL> archive log list;
可以在数据库处于装载状态时使用ALTER DATABASE 命令更改ARCHIVELOG 模式。
SQL> ALTER DATABASE [ archivelog | noarchivelog ]
将数据库模式从NOARCHIVELOG 模式更改为ARCHIVELOG 模式后，您必须备份所
有数据库文件和控制文件。您上一次的备份不再有用，因为它是在数据库处于NOARCHIVELOG 模式下备份的。
将数据库置于ARCHIVELOG 模式之后进行的新备份，将由所有以后的归档重做日志文件应用。将数据库设置为ARCHIVELOG 模式并不启用归档程序(ARCn) 进程。
通常，我们是将数据库由非归档模式改为归档模式的，但是，在数据仓库或者特殊的应用情况下，我们需要将数据库由归档模式改为非归档模式。
SQL> shutdown normal;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> archive log list

SQL> shutdown transactional;
SQL> shutdown immediate;
在设置归档、非归档之前，需要将数据库shutdown，有三个选项normal、transactional、immediate。
其他关闭数据库的方式不能正常的设置归档模式。也可以使用OEM(Oracle Enterprise Manager)改变数据库的归档模式。

设置归档目的地
使用LOG_ARCHIVE_DEST_n 最多可指定归档目标，LOG_ARCHIVE_DEST_n 是动态参数，可以在系统级或会话级对其进行修改。通过添加后缀1 到10，最多可以指定十个目标。
这些目标可位于本地磁盘和远程备用数据库：
log_archive_dest_1 = "LOCATION=/archive1"
log_archive_dest_2 = "SERVICE=standby_db1"
目标可以是本地文件系统位置，由关键字LOCATION 定义。指定的位置必须是有效的，并且不能是一个NFS 装载的目录。
也可以是远程目标的Oracle Net 别名，由关键字SERVICE 指定。指定的服务名通过使用本地的tnsnames.ora 文件进行解析，以标识远程数据库。
Oracle9i 支持使用IPC 或TCP/IP 协议将归档日志文件发送到远程节点。只能为每个远程数据库指定一个归档目标。必须为至少一个目标指定LOCATION 参数。
使用LOG_ARCHIVE_FORMAT 可在文件名中包括日志序列号和线程号。

归档目的地的mandatory与Optional
使用LOG_ARCHIVE_DEST_n 参数时，可以将目标指定为强制(mandatory) 或可选
(optional)，如下所示：
MANDATORY 表示必须成功完成归档到该目标的操作才可以覆盖联机重做日志文件。
OPTIONAL 表示即使联机重做日志文件尚未成功地归档到该目标，也可以重新使用。
这是缺省设置。
log_archive_dest_1="LOCATION=/archive/ MANDATORY REOPEN"
log_archive_dest_2="SERVICE=standby_db1 MANDATORY REOPEN=600"
log_archive_dest_3="LOCATION=/archive2/ OPTIONAL"

REOPEN 属性定义发生故障时是否必须重新尝试归档到目标。如果为关键字REOPEN
指定了值，如REOPEN=600，则若发生故障，在经过指定时间（以秒计）后，归档程序将尝试写入该目标。缺省值为300 秒。归档到目标的尝试次数没有限制。归档中的所有错误将在主站点的警报文件中报告。
如果未指定REOPEN，则可选目标上的错误将被记录并忽略。不再将重做日志发送到
这些目标。在归档成功之前，强制目标上的错误将导致无法重新使用联机重做日志。只要归档不成功，归档目标的状态就设置为ERROR。
可以使用联机重做日志文件之前需要成功归档的目标数量是根据以下设置决定的：定义为MANDATORY 的目标的数量，LOG_ARCHIVE_MIN_SUCCEED_DEST 参数的值。该参数用于为需要归档的本地目标数
指定一个下限值。如果该值小于强制本地目标的数量，则它对归档行为没有影响。如果该值大于强制本地目标的数量，则本地归档目标的数量必须至少等于该值，才可以重新使用联机重做日志文件。

将数据库设置为ARCHIVELOG 模式后，您必须决定是自动还是手动归档联机重做日志文件。这是创建归档重做日志文件以便用于恢复时的第二步。
在自动归档过程中，将启用ARCn 后台进程，该进程在重做日志文件填满后复制这些文件。在手动归档过程中，必须使用SQL*Plus 或Oracle Enterprise Manager 复制文件。

指定多个归档进程
将LOG_ARCHIVE_START 设置为TRUE 后，Oracle 例程将按照LOG_ARCHIVE_MAX_PROCESSES 定义的数量启动多个归档进程。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3;

可以在例程启动的时候设置自动归档：
如果数据库处于ARCHIVELOG 模式，通过设置以下参数，可以在每次启动数据库例程时启动归档程序进程：
LOG_ARCHIVE_START = boolean
如果Boolean 为TRUE，将在例程启动时自动启动n 个ARCn 进程，其中n 是由LOG_ARCHIVE_MAX_PROCESSES 确定的值。
如果Boolean 为FALSE，将禁止在例程启动时启动ARCn。
设置初始化参数后，ARCn 进程将在例程启动时自动启动，而无需您手动启动自动归档。也可以在例程启动之后启用自动归档
可以选择使用带有TO 选项的ALTER SYSTEM ARCHIVE LOG START 命令指定归档目标。例如：
UNIX :SQL> ALTER SYSTEM ARCHIVE LOG START TO '/ORADATA/ARCHIVE1';
如果已启用ARCn 进程，则执行以下命令以停止ARCn 进程：
SQL> ALTER SYSTEM ARCHIVE LOG STOP;
停止ARCn 进程并不会将数据库设置为NOARCHIVELOG 模式。如果所有重做日志组都已使用但未归档，处于ARCHIVELOG 模式的数据库将会停止。

手动归档
如果数据库处于ARCHIVELOG 模式，且未启用自动归档，则必须手动归档联机重做日志文件。发出下面的命令进行手动归档：
ALTER SYSTEM ARCHIVE LOG CURRENT;

手动归档联机重做日志文件时，可以在ALTER SYSTEM ARCHIVE LOG 命令中使用以下选项：
选项            说明
THREAD            指定包含要归档的重做日志文件组的线程（用于Oracle Parallel Server）
SEQUENCE        归档由日志序列号标识的联机重做日志文件组
CHANGE            基于SCN 进行归档
GROUP            归档联机重做日志文件组
CURRENT            归档指定线程的当前重做日志文件组
LOGFILE            归档包含有由文件名标识的成员的重做日志文件组
NEXT            将尚未归档的最旧的联机重做日志文件组进行归档
ALL                对指定线程的已满但尚未归档的所有联机重做日志文件组进行归档
START            启用重做日志文件组的自动归档
TO                指定重做日志文件组归档的目标位置
STOP            禁用重做日志文件组的自动归档

控制归档到目标
归档目标的状态可以动态地进行更改。缺省情况下，归档目标是ENABLE 状态，表明
Oracle 服务器可以使用该目标。归档目标的状态可以通过设置相应的LOG_ARCHIVE_DEST_STATE_n 参数来进行修改。
例如，要在发生错误时暂时停止归档到强制位置，可以将该目标的状态设置为DEFER。
在参数文件中可能定义了一个目标，但它设置为DEFER。当另一目标出现错误或需要维护时，可以启用该目标。
如果一个目标的状态设置为DEFER，则不会执行归档到该目标的操作。如果该目标
的状态更改为ENABLE，则必须手动将所有缺失的日志归档到该目标。

指定归档文件格式
通过指定LOG_ARCHIVE_FORMAT = extension参数来指定归档的文件格式，其中，extension 应包括日志序列号变量%s 或%S。缺省值是根据操作系统而定的。如下：
UNIX：LOG_ARCHIVE_FORMAT=arch%s.arc
Windows NT：LOG_ARCHIVE_FORMAT = %%ORACLE_SID%%T%TS%S.ARC，其中，
%ORACLE_SID% 被转换为数据库SID
文件名选项：
%s 或%S：包括日志序列号，作为文件名的一部分。
%t 或%T：包括线程号，作为文件名的一部分。
使用%S 可通过在值的左侧用0 来填补空位使该值长度保持固定。

与归档相关的动态视图有以下几个：V$ARCHIVED_LOG、V$ARCHIVE_DEST、V$LOG_HISTORY、V$DATABASE、V$ARCHIVE_PROCESSES。
v$archived_log视图显示控制文件中的归档日志信息。
V$ARCHIVE_DEST视图对于当前例程，说明所有归档日志目标、当前值、模式和状态。
v$log_history包含控制文件中的日志文件信息。
V$DATABASE视图显示归档的当前状态。
V$ARCHIVE_PROCESSES提供有关例程的各种ARCH 进程的状态的信息。
数据库备份、还原、恢复的基本原理
备份可以分为逻辑备份与物理备份。简单的说，逻辑备份是按数据库中数据的备份，物理备份是按存储介质，数据文件的备份。

实例恢复：
当数据库实例发生故障而发生停机，或用户利用abort选项关闭实例后，数据库再启动后会自动执行实例恢复，实例恢复会回滚上次实例运行时未提交的事务以及一些其他的动作，
将数据库恢复到一致状态，这个过程对于用户来说是透明的，由实例自动进行，不需要人工干预。

检查点与CKPT进程
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。
巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，
按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，
而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。
每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。
增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。
由于增量检查点和checkpoint queue 的原理，ckpt 进程每次只是告诉dbwr ，写dirty buffer将要一直写到最新这个位置，仅仅是告诉dbwr 一个checkpoint queue 中的结束点，
而ckpt 每3秒钟，在控制文件中报告一下dbwr 最新写入的位置。这样使得，比如数据库要做恢复的时候（instance recovery）可以从这个最新位置开始做恢复，
而不是从数据文件中的checkpoint scn 开始做恢复，这样将缩短恢复时间，尤其是instance crash 的情况下启动更快。
要注意的是，检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去，
也就是说，更新控制文件和数据文件头是 滞后于检查点的发生的，这个从恢复的原理也很容易理解，因为检查点发生的时候dirty buffer还没有写入，自然不能立即更新成当前的scn 了。
DBWn来写脏数据(SIGNALLING DBWn at CKPT)，完后会更新DATAFILE的HEADER和控制文件的HEADER.而HEADER中有同步所需要的信息,即CHECKPOINT的信息。
在ORACLE中，正常情况下，所有文件必须同期性地同步;靠CHECKPOINT来完成。

日志
oracle在记录日志的方式上，采用了逻辑和物理相结合的方式。
通过这种方式，oracle获得了物理记录方式的快速恢复的优点，同时又获得了逻辑记录方式的节省空间的优点。

一个日志文件写满以后转换到另外一个日志文件继续写的过程叫做日志切换（log switch）。
当一个联机日志文件写满时，可以选择将其归档为脱机日志文件，通常叫做归档日志文件。归档也就是拷贝，归档的过程也就是将写满的联机日志文件拷贝到预先指定的目录的过程。
只有当一个联机日志文件完成归档以后，该联机日志文件才能够被再次循环使用。
LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。

Oracle环境中可能发现的故障类型：语句故障、用户进程故障、用户错误、网络故障、例程故障、介质故障。
语句故障
在Oracle 程序中处理语句时如果出现逻辑故障就会导致语句故障。语句故障的类型包括：
应用程序中出现逻辑错误。
用户试图向表中输入无效数据，可能破坏完整性约束。
用户权限不足却试图执行某个操作，例如只有SELECT 权限却在表中执行插入操作。
用户试图创建表，但超出了分配给该用户的限额限制。
用户试图对表执行INSERT 或UPDATE 操作，导致分配了一个区，但是表空间中的可用空间不足。
如果遇到语句故障，Oracle 服务器或操作系统将返回错误代码和错误消息。失败的SQL 语句将自动回退，然后控制权将返回给用户程序。应用程序开发人员或DBA 可使用Oracle 错误代码来诊断和帮助解决故障。

用户进程故障
用户进程失败的原因可能有多种；但最常见的原因如下：
用户在会话中执行了异常断开操作。例如，用户在连接到客户机-服务器配置环境中的数据库的情况下，关闭了SQL*Plus 窗口。
用户会话被异常终止。一种可能的情况是用户在连接到客户机-服务器配置环境中的数据库时重新引导了客户机。
用户程序导致地址异常，从而终止会话。如果在发生异常时，应用程序未对这些异常进行正确处理，则通常会发生这种情况。
出现异常终止的用户进程后，PMON 后台进程通常足以清理该用户进程。PMON 进程检测到异常终止的服务器进程时，它将回退该异常终止进程的事务处理，并释放它所获得的任何资源和锁。

用户错误
用户错误通常包括以下几种：
用户意外地删除或截断表。用户删除表中的所有行。用户提交了数据，但在其中发现一个错误。
我们无法完全避免用户错误，只能尽可能减少用户错误，在任何数据库和应用程序环境中，一个关键的问题就是确保用户已经过适当培训，并且知道数据库可用性和完整性的含义。
DBA 应该了解应用程序和商业运作的类型，这可避免由于用户错误而导致数据丢失；
DBA 还应该了解在这些情况下如何采取恢复措施。
某些恢复情况涉及的范围可能很广，例如将数据库还原到出现错误之前的时间点、导出丢失的数据，然后将数据导入到丢失了该数据的数据库。
LogMiner 是一种关系工具，通过它，可以以使用SQL 来阅读、分析、解释联机和归档日志文件。使用LogMiner 分析日志文件可用来查明何时对数据库进行了错误的修改。这样，就可以在应用程序级（而不是在数据库级）执行逻辑恢复了。
Oracle9i 提供一种称为FlashBack 的新功能，可以以用它来查看和修复历史数据。
FlashBack 提供对截止某一特定时间或用户指定的系统提交号(SCN) 的数据库执行查询的功能。

数据库崩溃与实例恢复
数据库崩溃的原因可能有多种：
由于断电，导致服务器不可用。由于硬件问题（如CPU 故障或内存损坏）或操作系统崩溃而导致服务器不可用。某个Oracle 服务器后台进程（DBWn、LGWR、PMON、SMON 或CKPT）出现故障。
要从崩溃中恢复，DBA 可以使用“startup” 命令启动例程。Oracle 服务器将自动恢复，并执行前滚和回退阶段。通过阅读警报日志和在例程故障期间生成的其它所有跟踪文件来调查故障原因。
崩溃恢复和例程恢复将数据库恢复到发生例程故障之前的事务处理一致状态。
根据定义，崩溃恢复是对单例程配置中的数据库或Oracle Real Application Clusters 配置（其中的所有例程都已崩溃）中的数据库执行的恢复；
而例程恢复是通过Oracle Real Application Clusters 配置中的一个活动例程来恢复一个失败的例程。如果需要，可以在数据库打开时，由Oracle 服务器自动执行崩溃恢复。
您不必执行任何恢复操作。所有必需的重做信息都由SMON 来读取。要从这种类型的故障中进行恢复，请启动例程：
SQL> CONNECT / AS sysdba
SQL> STARTUP
数据库打开后，通知用户必须重新输入未提交的所有数据。
在启动数据库和出现“数据库已打开” (Database opened) 通知之间可能有一个时间延迟，这是数据库装载时发生的前滚阶段。
SMON 通过应用联机重做日志文件（来自最后一个检查点）中记录的更改来执行前滚进程。前滚可恢复尚未记录到数据库文件中、但已记录到联机重做日志中的数据，包括还原段的内容。
打开数据库时可能发生回退，原因是无论SMON 或是服务器进程都可以执行回退操作。这使数据库可以更快地供用户使用。

介质故障与介质恢复
介质故障包含对操作数据库所需的文件进行读写操作时产生的物理问题。介质故障是最严重的故障类型，原因是它通常需要DBA的干预。
与介质有关的问题的常见类型：
包含某一数据库文件的磁盘驱动器出现磁头损坏。
对实现正常数据库操作所需的文件进行读写操作时存在物理问题。
文件被意外删除。
经过测试的恢复策略是解决介质故障问题的关键要素。DBA 能够在多大程度上尽量减少由介质故障引起的停机时间和数据损失取决于可用备份的类型。因此，恢复策略取决于以下因素：
选择的备份方法以及受到影响的文件。
数据库操作的ARCHIVELOG 模式。如果采用归档，可以应用已归档的重做日志文件来恢复自上次备份以来所提交的数据；如果使用RMAN，还可以应用增量备份。

备份和恢复策略
典型的备份策略：
1、镜像拷贝重作日志文件；
2、镜像拷贝控制文件；
3、激活归档进程，即以ARCHIVELOG模式操作数据库；
4、每天进行数据库的部分联机备份（每天进行数据库的完全热备份将无畏地增加数据库的负担且没有必要，同时也增加了数据库恢复时的灵活性）；
5、每隔一周或几周进行一次数据库的逻辑备份；
6、定期检查备份是否正常，定期测试备份的可恢复性以及恢复时间。

DBWR进程总是比LGWR进程写的速度慢（DBWR进程是随机写，LGWR进程是顺序写，随机写比顺序写要慢）当DBWR进程要将缓存区中的信息写入到数据文件时，
会先通知LGWR进程将事务相关的redo信息写入到日志文件。SCN可以理解为一个标签，ORACLE对数据库中的每个操作都打上一个标签。这个标签是顺序增加的。
永远不会归0（除非数据库重建）CHECKPOINT是ORACLE为了记录哪些数据已经被写入到数据文件中。

Instance Recovery所需要的信息，就是最近一次checkpoint之后到日志文件结尾的这些redo信息。
因为checkpoint之前的数据都已经一致性地写入到数据文件中了，而之后的数据可能有一部分已经写进数据文件，而有一部分没有写进数据文件。
Instance Recovery所需要的时间，将数据文件从最近一次checkpoint开始，恢复到控制文件中记录的这个数据文件的最后一个SCN值为止，应用这两者之间redo信息的时间就是instance recovery所要花费的时间。

对于instance recovery花费时间的调优，就是对参数FAST_START_MTTR_TARGE的调整，单位“秒”，最大值为3600秒。
也就是说FAST_START_MTTR_TARGET这个参数的设置会直接影响到checkpoint发生的频率。
FAST_START_MTTR_TARGE所设置的时间就是用户希望数据库用在instance recovery的时间。也就是从应用最近一次checkpoint到日志信息最后这两个点之间redo信息所要花费的时间。
MTTR设置的时间过小的话，会造成系统checkpoint过于频繁，而发生checkpoint时就要DBWR，LGWR等进程写数据文件，产生物理IO，久而久之，数据库性能会越来越慢；
MTTR设置的时间过大的话，当实例失败时，instance recover所花费的时间就会过长。

++++++++++++++++++++++++++++++++++++++
用户管理的备份
整体数据库备份：备份数据库中每一个关键文件，包括所有数据文件、重做日志文件、控制文件和参数文件
表空间备份：只备份指定表空间下的所有数据文件
数据文件备份：只备份指定的数据文件
控制文件备份：只备份某一时候的控制文件

整体数据库备份：
整体数据库备份（也称为整体备份）是指对数据库的所有数据文件和控制文件进行备份。无论数据库是打开的还是关闭的，都可以执行整体备份。这是最常见的备份方法。
在数据库关闭（使用NORMAL、IMMEDIATE 或TRANSACTIONAL 选项关闭数据库）后进行的整体备份称为一致备份。
在这种备份中，所有数据库文件的标头均与控制文件一致，完全还原后，数据库不需任何恢复即可打开。数据库以NOARCHIVELOG 模式进行操作时，只有一致的整体数据库备份才可以用来还原和恢复。
如果数据库打开并且可操作，数据文件的标头将与控制文件不一致，除非数据库是以只读模式打开的。
如果使用ABORT 选项关闭数据库，这种不一致性将一直存在。这种状态下的数据库备份称为不一致备份。
不一致备份需要通过恢复才能使数据库进入一致状态。如果数据库需要每周7 天、每天24 小时都可用，则只能使用不一致备份，并且只能对以ARCHIVELOG 模式运行的数据库执行不一致备份。

表空间备份：
表空间备份是对组成表空间的数据文件进行的备份。只有当数据库处在ARCHIVELOG 模式下时表空间备份才有效，因为要使数据文件与数据库的其它部分保持一致，需要使用重做条目。
在NOARCHIVELOG 模式下，如果数据库为只读的或脱机正常的，可以以进行表空间备份。

数据文件备份：
如果数据库处在ARCHIVELOG 模式下，可以以对单个数据文件进行备份。在NOARCHIVELOG 模式下，可以以对只读或脱机正常的数据文件进行备份。

控制文件备份：
可以以对RMAN 进行配置，使之在发出BACKUP 或COPY 命令后自动备份控制文件。还可以通过SQL 命令备份控制文件。

用户管理的备份恢复，也就是在备份时由用户自己使用操作系统提供的复制命令，复制要备份的文件。
相关视图：V$DATAFILE、V$CONTROLFILE、V$LOGFILE 和V$TABLESPACE

冷备份
冷备份的概念：关闭数据库的备份
冷备份的优点：恢复后可以直接使用
冷备份的缺点：必须关闭数据库
冷备份的执行过程：先关闭数据库，再复制所有重要文件

进行数据库冷备份的优点：
冷备份在概念上简明易懂，您只需：关闭数据库，将所有需要的文件复制到备份位置，打开数据库要执行关闭的数据库的备份，只需使用数量极少的几个命令。
只要执行一个简单的脚本，而且只需很少的交互操作，就可以自动的数据库的冷备份，步骤如下：关闭数据库，复制控制文件和数据文件，打开数据库。
所有在冷备份过程中复制的文件都具有一致的时间点。在备份过程中，由于数据库不可用，因此不发生任何事务处理。
进行数据库冷备份的缺点：
对于数据库必须处于连续可用状态的那些业务经营活动，由于在一致的整体数据库备份期间数据库会关闭且不可用，所以不能采用这种备份方式。
数据库不可用的时间长短受数据库大小、数据文件的数量以及复制数据文件的速度的影响。如果这一时间超过了允许的关机时间，您必须选择其它备份类型。
只能恢复到上一次完全一致的整体数据库备份时的状态，丢失的事务处理必须在执行恢复操作之后手动输入。

热备份
热备份是在数据库运行时对数据库进行备份，应该注意：
联机表空间备份
只读表空间备份
备份控制文件和初始化参数文件
在联机备份失败后执行清除

执行所有表空间或各个数据文件的备份（无论它们处在联机状态还是脱机状态）。
将控制文件备份为一个二进制文件，或创建一个脚本以重新创建控制文件。联机重做日志文件不需要备份。这种备份称为热备份。
热备份的优点：
在备份过程中数据库可以正常使用。可以在表空间级（通过RMAN）或数据文件级执行备份。支持每天都全天候运作的业务。
热备份的条件：
只要符合以下两个标准，您就可以在使用数据库的同时，执行表空间或各个数据文件的备份：
数据库设置为ARCHIVELOG 模式。通过启用Oracle 自动归档(ARCn) 进程或手动归档重做日志文件，确保联机重做日志得到归档。
热备份的选项：
使用Oracle 服务器，我们既可以备份某一特定表空间的所有数据文件，也可以只备份某个表空间的一个数据文件。无论您选择哪个选项，在备份过程中，数据库都可以保持正常使用（事务处理）。
如果一个数据文件处于备份模式，则可能会生成多个重做日志条目，因为日志写入器将备份模式下的数据文件中已更改的块的块映像写入重做日志，而不仅仅是写入行信息。
这会对重做日志的大小和日志写入器的性能产生重大影响。

通过以下步骤可以进行联机表空间的备份：
1. 通过发出ALTER TABLESPACE...BEGIN BACKUP 命令，将数据文件或表空间设置为备份模式。这样可避免数据文件头中的序列号发生变化，以便恢复时可以从备份开始时间应用日志。
即使数据文件处于备份模式，仍可用于正常事务处理。
SQL> ALTER TABLESPACE users BEGIN BACKUP;
2. 使用操作系统备份实用程序将表空间中的所有数据文件复制到备份存储中。如果按顺序备份每个表空间，备份文件中的日志序列号可能不同。
UNIX:
cp /ORADATA/u03/users01.dbf /BACKUP/users01.dbf
Windows NT:
ocopy c:\users\disk1\user01.ora e:\users\backup\user01.ora
3. 备份表空间的各数据文件后，发出下面的命令将它们设置为正常模式：
SQL> ALTER TABLESPACE users END BACKUP;
4. 归档尚未归档的重做日志，以便归档恢复表空间备份所需的重做日志，
如下所示：
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
对所有表空间重复这些步骤，包括SYSTEM 和还原段表空间。
ALTER TABLESPACE BEGIN BACKUP 和ALTER TABLESPACE END
BACKUP 命令之间的间隔时间应尽量缩短，因为修改后的块写入重做日志文件
将导致生成更多的重做信息。因此建议您每次执行一个表空间的联机备份。
通过查询V$BACKUP 和V$DATAFILE_HEADER 视图，可以在执行打开的数据库的备份时获得关于数据文件状态的信息。
查询V$BACKUP 视图以确定哪些文件处于备份模式。发出ALTER
TABLESPACE BEGIN BACKUP 命令后，状态将更改为ACTIVE。

只读表空间可以通过下面的方法备份：
1 使用ALTER TABLESPACE SQL 命令将表空间的状态从读写更改为只读：
SQL> ALTER TABLESPACE query_data READ ONLY;
2 发出ALTER TABLESPACE 命令后，会对所有与表空间相关联的数据文件执行检查点。然后使用当前SCN 冻结文件头。
3 使表空间成为只读状态之后，您必须备份该表空间的所有数据文件。
4 DBW0 进程只写入其表空间处于读写模式的数据文件，正常的检查点也只对这些文件执行。
对只读表空间的说明：
由于不对只读表空间的数据文件执行任何写操作，因此，只有在这些文件损坏的情况下才必须进行恢复。
将表空间从只读状态更改为读写状态，其结果是导致DBW0 写入表空间文
件，并象通常一样产生检查点。这样，您就必须对与该表空间相关联的所有数据文件重新使用正常备份时间表。
使用ALTER TABLESPACE 命令将表空间更改为只读状态，会导致控制文
件更新。执行恢复操作时，控制文件必须能够正确地标识只读表空间；否则，您必须恢复该表空间。

备份控制文件和初始化参数
Oracle 服务器在进行例程或介质恢复时会用到控制文件中的某些状态信息（如当前联机重做日志文件以及数据库文件的名称）。每次对数据库配置进行更改后，您都需要保留控制文件的最新副本。
备份的原则：
对控制文件进行多元备份，并使用CONTROL_FILES 参数在init.ora 文件中为它们命名。
ALTER DATABASE BACKUP CONTROLFILE TO TRACE 命令创建一个用于重新创建控制文件的脚本。
该文件位于由初始化参数USER_DUMP_DEST 指定的目录下。此脚本不包含RMAN 元数据。此外，还应使用ALTER DATABASE BACKUP CONTROLFILE 命令来备份各个控制文件。
这样可以提供控制文件在该时间点的二进制副本。完全备份时，正常关闭例程，然后使用操作系统备份实用程序将控制文件复制到备份存储中。

可以以使用CREATE PFILE 语句来创建服务器参数文件的备份。服务器参数
文件的内容以文本格式导出到一个初始化参数文件中。CREATE PFILE 命令可以在缺省位置创建该文件，您也可以按示例指定文件名。
CREATE PFILE = '/backup/init.ora' FROM SPFILE;
CREATE PFILE FROM SPFILE;

在联机备份失败后执行清除
联机表空间备份过程中的故障处理：
在联机表空间备份的过程中，可能会发生系统崩溃、电源故障、数据库关闭等故障。一旦发生任何这些故障：如果操作系统未完成备份，则备份文件将不可用。
您需要重新备份这些文件。处在联机备份模式下的数据库文件不会与数据库同步，原因是备份开始时标头被冻结。
数据库将不会打开，因为Oracle 服务器认为文件已从备份中还原。可以以使用ALTER DATABASE …END BACKUP 命令使数据文件脱离备份模式。
只有在您确定这些文件处于备份模式、且未从备份中还原的情况下，才可使用此命令。
如果您不能确定某一文件是否需要恢复，或者该文件是否仍处于联机备份模式，可查询V$BACKUP 视图：
SQL> ALTER DATABASE datafile 2 END BACKUP;
SQL> ALTER DATABASE END BACKUP;
SQL> ALTER DATABASE OPEN;

使用DBVERIFY实用程序检测坏块
DBVERIFY程序的作用：检测数据文件是否有坏块
DBVERIFY 实用程序的可执行程序名称在不同操作系统中是不同的。它位于Oracle 主目录的bin 目录中。在UNIX 环境中，应执行dbv 可执行程序。
该实用程序主要用于以下两个目的：确保备份数据库（或数据文件）在还原之前是有效的；遇到数据损坏问题时用作诊断辅助工具。
要验证数据文件users01.dbf 的完整性（从块1 开始到块500 结束），可以以执行如下命令：
$ dbv file=/ORADATA/u03/users01.dbf start=1 end=500
参数的说明：
参数        说明
FILE        要验证的数据库文件的名称
START        验证的块的起始地址。块地址在Oracle 块中指定。如果不指定START，则假定起始地址为文件中的第一个块。
END            要验证的块的结束地址。如果不指定END，则假定结束地址为文件中的最后一个块。
BLOCKSIZE    仅在文件中有大于2KB 的块时才需要此参数
LOGFILE        指定事件记录信息写入的文件。缺省设置是将输出发送到终端显示器。
FEEDBACK    使DBVERIFY 为已验证的n 页显示单个‘.’
HELP        提供屏上帮助
PARFILE        指定要使用的参数文件的名称

介质恢复
介质恢复用于恢复丢失的或损坏的当前数据文件或控制文件。它还可用于恢复数据文件脱机时由于未使用OFFLINE NORMAL 选项而丢失的那些更改。
首先是还原文件(RESTORE)，在还原文件时，其实是使用备份副本替代丢失的或损坏的文件。然后是文件恢复(RECOVER)，在恢复文件时，将重做日志文件中记录的更改应用到所还原的文件中。
介质恢复的步骤如下：
从备份还原损坏的或丢失的文件。
根据需要应用归档重做日志文件和联机重做日志文件中的更改。此时将生成还原块。这称为前滚或高速缓存恢复。
数据库此时可能包含已提交的和未提交的更改。
还原块用于回退任何未提交的更改。这称为回退或事务处理恢复。
数据库现处于已恢复状态。
在还原文件时，使用操作系统命令从备份中复制文件。可以还原数据文件、控制文件、归档重做日志文件和服务器参数文件。
使用SQL*Plus RECOVER 命令将重做日志文件应用到还原的文件中。可以执行自动恢复，或者逐个查看日志文件以应用更改。

在NOARCHIVELOG 模式下，即使只有一个数据文件被损坏或丢失，也必须还原所有的Oracle 数据库文件。确保还原以下所有文件：数据文件和控制文件。
如果您在备份数据文件和控制文件时还备份了联机重做日志文件，则还要还原这些文件。切记，必须将所有的Oracle 数据库文件进行同步，以打开该数据库。
仅当口令文件和参数文件被损坏或丢失时，才应该还原它们。
对于处于NOARCHIVELOG 模式下的数据库，如果自上次备份以来没有覆盖任何重做日志文件，则只需还原受影响的Oracle 数据文件
是否决定在NOARCHIVELOG 模式下操作数据库，应考虑在恢复时的以下优缺点：
优点：易于操作，原因是只需从一个备份中还原所有的文件。唯一的风险在于操作本身：还原错误的备份、覆盖备份、还原之前未关闭数据库或者备份无效。
经过充分的培训和测试，可最大限度地降低此类风险。在给定的硬件和操作系统下，恢复时间只是还原所有文件所花的时间长度。
缺点：自上一次备份后用户输入的所有数据将丢失，必须手动重新应用。,即使只丢失了一个数据文件，也必须从上次执行的、关闭的数据库的整体备份中还原整个数据库。

示例1：
使用重做日志备份恢复。磁盘2 被损坏，结果丢失了数据文件2。仅有2 个联机重做日志文件。
上次备份是在日志序列144 进行的，当前日志序列号为146。
不能恢复该数据文件，因为重做日志144 已被覆盖。如果尝试进行恢复，将会证实这一问题。因此，必须关闭数据库并还原所有的Oracle 文件。
SQL> SHUTDOWN ABORT
要还原文件，请：
UNIX: cp /BACKUP/* /databases/db01/ORADATA
Windows NT: copy d:\disk1\backup\*.* d:\disk1\data\
复制结束后，重新启动例程：
SQL> CONNECT / as sysdba
SQL> STARTUP
通知用户，他们需要重新输入自上一次备份以后输入的数据。

示例2：
不使用重做日志备份进行恢复。
如果数据库已打开，则按如下方式关闭它：
SQL> SHUTDOWN IMMEDIATE
使用操作系统命令还原对数据库的最新而且完整的备份。必须还原所有的数据文件和控制文件，而不仅仅是还原损坏的文件。以下示例还原了数据库的完整备份：
$ cp /db01/BACKUP/*.dbf /ORADATA/u*/* # restores datafiles
$ cp /db01/BACKUP/*.ctl /ORADATA/u*/* # restores control file
因为您没有备份联机重做日志，所以不能使用数据文件和控制文件还原它们。因此，Oracle 允许重置联机重做日志，您必须按如下方式仿效进行不完全恢复：
SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE
SQL> CANCEL
然后，使用RESETLOGS 选项打开数据库，将当前的重做日志序列重置为1（如下所示）：
SQL> ALTER DATABASE OPEN RESETLOGS;

在ARCHIVELOG 模式下执行完全恢复
在执行介质恢复时，您将还原的文件更新到当前时间，或者更新到由用户指定的、除当前时间之外的时间。
在完全恢复中，使用重做日志文件或增量备份将还原文件更新到最近的时间点。将归档重做日志文件和联机重做日志文件中包含的重做更改全部应用到这些文件中。
可以对数据库表空间或数据文件执行完全恢复。对于不完全恢复，其实就是将数据库恢复到当前时间以前的某一时刻。通常，您并不会应用备份后生成的所有重做条目。
完全恢复要确保要还原的数据文件处于脱机状态。仅还原丢失的或损坏的数据文件。不要还原控制文件、重做日志文件、口令文件或参数文件。恢复数据文件。
当处于ARCHIVELOG 模式的数据库发生介质故障时，需要使用以下内容将数据库完全恢复到发生故障前那一刻的情形：
在将数据库设置为ARCHIVELOG 模式后进行的有效备份（其中包含丢失的或损坏的
数据文件），从您所使用的备份起至今的所有归档日志，包含尚未归档的事务处理的重做日志文件。
在ARCHIVELOG 模式下进行完全恢复的优缺点：
优点：仅需还原丢失或损坏的文件。已提交的数据不会丢失。通过还原上述文件并应用归档日志和重做日志，就可将数据库恢复至当前的时间点。
恢复的总时间就等于还原文件并应用所有归档日志和重做日志所需的时间。可以在数据库打开的情况下进行恢复（包含联机还原段的系统表空间文件和数据文件除外）。
缺点：必须有自上次备份起到当前时间的所有归档重做日志文件。
如果缺失一个文件，则无法执行完全恢复，原因是必须依次应用所有的归档重做日志文件；即，先应用归档日志144，其次是145，再次是146，以此类推。
要确定需要恢复哪些数据文件以及需要从哪里开始恢复，请按如下方式使用
V$RECOVER_FILE 视图：SQL> SELECT * FROM v$recover_file;
要查找归档日志文件，可查看V$ARCHIVED_LOG 以获得所有归档日志文件，或查看V$RECOVERY_LOG 以获得恢复时所需的归档日志文件：

使用用户管理的过程将数据文件还原到新的位置：
1. 使用操作系统命令将文件还原到新的位置。
注：在UNIX 环境中，在发出ALTER DATABASE RENAME 命令之前，文件必
须位于新位置。在Windows NT 环境中，则不必如此。
2. 启动该例程并装载数据库。
3. 使用ALTER DATABASE 命令来更新控制文件，将其更新为新的文件名或更新到
新的位置：
SQL> ALTER DATABASE RENAME FILE
2> ‘/ORADATA/u03/users01.dbf‘
3> to ‘/ORADATA/u04/users01.dbf‘;

完全恢复的方法：
执行完全恢复的方法有4 种：
方法1：恢复关闭的数据库
此方法适用于以下情况：数据库不是全天候（每周7 天、每天24 小时）运行。恢复的文件属于系统表空间或还原段表空间。需要恢复整个数据库或大部分数据文件。
方法2：恢复打开的数据库（数据库最初是打开的）
此恢复方法一般在以下情况下使用：发生了文件损坏、文件意外丢失或介质故障，但未导致数据库关闭。数据库全天候（每周7 天、每天24 小时）运行。
必须最大限度地减少数据库的停机时间。恢复的文件不属于系统表空间或还原段表空间。
方法3：恢复打开的数据库（数据库最初是关闭的）
此恢复方法一般在以下情况下使用：某个介质故障或硬件故障导致系统关闭。数据库全天候（每周7 天、每天24 小时）运行。必须最大限度地减少数据库的停机时间。还原的文件不属于系统表空间或还原段表空间。
方法4：在没有备份的情况下恢复数据文件
此恢复方法一般在以下情况下使用：介质故障或用户故障导致丢失了从未备份过的数据文件。自该文件创建以来的所有归档日志都存在。还原的文件不属于系统表空间或还原段表空间。
恢复过程中，磁盘中必须有Oracle 服务器所需的所有归档日志文件。如果这些文件在备份磁带中，则必须先还原这些文件。

完全恢复关闭的数据库
在以下情况中，通常将此恢复方法与RECOVER DATABASE 命令或RECOVER DATAFILE命令一起使用：
恢复的文件属于系统表空间或回退段表空间。需要恢复整个数据库或大部分数据文件。数据库不是全天候（每周7 天、每天24 小时）运行。示例：
已确定u01（数据文件1 存储在其中）包含被损坏的块。通过查询V$DATAFILE 和V$TABLESPACE 视图，可以发现数据文件1 是系统表空间所属的文件之一。请按照以下步骤恢复数据库：
1. 如果例程尚未关闭，请按如下方式发出SHUTDOWN 命令：
SQL> SHUTDOWN ABORT
2. 从备份（可用的最新备份）中还原该文件：
UNIX> host cp /BACKUP/system01.dbf /ORADATA/u01
Windows NT > host copy c:\backup\df1.dbf d:\data\
3. 以“装载” 模式启动例程，并恢复该数据文件：
SQL> STARTUP MOUNT
SQL> RECOVER DATABASE
or SQL> RECOVER DATAFILE ‘/ORADATA/u01/system01.dbf‘
要将数据文件恢复到发生故障前的那一刻，应该应用所有需要的归档日志和重做日
志。
4. 恢复结束后，所有数据文件都将实现同步。打开数据库。
SQL> ALTER DATABASE OPEN;
此时，可通知用户数据库可以使用了，并告诉他们重新输入系统发生故障前未提交的所有数据。
在使用此恢复方法进行恢复的期间，必须关闭数据库；在恢复进程中，整个数据库都无法让用户进行访问。

恢复打开的数据库（数据库最初是打开的）
此恢复方法一般在以下情况下使用：
未导致数据库关闭的文件损坏、文件意外丢失或介质故障。数据库全天候（每周7 天、每天24 小时）运行。必须最大限度地减少数据库的停机时间。受到影响的文件不属于系统表空间或还原/回退段表空间。示例：
数据库当前已打开，并且已使用操作系统命令误删了数据文件2。因为数据库当前已打开，所以可以使用以下命令确定该数据文件属于哪个表空间：
SQL> SELECT file_id f#, file_name,
2> tablespace_name tablespace, status
3> FROM dba_data_files;
1. 发出以下查询，以确定是否需要将数据文件2 脱机：
SQL> SELECT d.file# f#, d.name, d.status, h.status
2> FROM v$datafile d, v$datafile_header h
3> WHERE d.file# = h.file#;
2. 因为该文件处于脱机状态，所以此时可从备份中还原该文件：
UNIX > host cp /disk1/backup/df2.dbf /disk2/data/
Windows NT > host copy c:\backup\df2.dbf d:\data\
3. 使用RECOVER 命令将归档和重做日志应用到还原的数据文件中。
SQL> RECOVER DATAFILE ‘/disk2/backup/df2.dbf‘
or SQL> RECOVER TABLESPACE user_data
4. 恢复结束后，所有数据文件都将实现同步。将该数据文件联机：
SQL> ALTER DATABASE DATAFILE ‘/disk2/data/df2.dbf‘ ONLINE;
或SQL> ALTER TABLESPACE user_data ONLINE;

有时Oracle 服务器会检测到某个文件有问题并自动将该文件脱机。在进行恢复之前，一定要查看警报日志以检查是否有任何错误，并检查文件的状态；可能需要恢复脱机文件。
在将表空间脱机后，就会将其所有数据文件脱机，并且无法访问该表空间中包含的任何数据。
对于具有多个文件的表空间来说，如果将其中一个数据文件脱机，则只有该数据文件中包含的数据无法进行访问，而表空间仍然可以使用。


恢复打开的数据库（数据库最初是关闭的）此恢复方法一般在以下情况下使用：介质或硬件故障导致系统关闭。
数据库全天候（每周7 天、每天24 小时）运行。必须最大限度地减少数据库的停机时间。损坏的文件不属于系统表空间或还原段表空间。示例：
您刚刚确定介质故障是由于某个磁盘控制器发生故障而引起的，该控制器只包含磁盘2。
根据您对数据库的了解，您知道数据文件2 不是系统数据文件或还原段数据文件，并且并不会由于无法使用该文件而妨碍用户运行其月末报告。
1. 装载该数据库。由于数据文件2 无法打开，因此无法打开该数据库。
SQL> STARTUP MOUNT
2. 如果该数据文件未脱机，则无法打开数据库。因此，必须将该文件脱机。您已经
查询了V$DATAFILE 并确定该文件处于联机状态。
SQL> ALTER DATABASE datafile ‘/disk2/data/df2.dbf‘ offline;
注：此时不能使用ALTER TABLESPACE 命令，原因是数据库尚未打开。
3. 然后就可以打开数据库，使用户能够访问系统：
SQL> ALTER DATABASE OPEN;
4. 然后，还原该文件。因为无法将文件还原到损坏的磁盘2 上，所以将它还原到磁盘3 上：
UNIX > host cp /disk1/backup/df2.dbf /disk3/data/
Windows NT > host copy c:\backup\df2.dbf e:\data\
现在必须通知Oracle 服务器新文件的位置：
SQL> ALTER DATABASE rename file ‘/disk2/data/df2.dbf‘
2> to ‘/disk3/data/df2.dbf‘;
如果数据库已打开并且需要恢复表空间，请发出以下查询，以确定该数据文件所属的表空间的名称：
SQL> SELECT file_id f#, file_name,
2> tablespace_name tablespace, status
3> FROM dba_data_files;
5. 使用RECOVER 或ALTER DATABASE RECOVER 命令开始将归档重做日志文件和联
机重做日志文件应用到还原的数据文件中。
SQL> RECOVER DATAFILE ‘/disk3/data/df2.dbf‘
或SQL> RECOVER TABLESPACE user_data
6. 恢复结束后，所有数据文件都将实现同步。将该数据文件联机：
SQL> ALTER DATABASE datafile ‘/disk3/data/df2.dbf‘ online;
或SQL> ALTER TABLESPACE user_data online;

在没有备份的情况下恢复数据文件，此恢复方法一般在下列情况使用：介质故障或用户故障导致丢失了从未备份过的数据文件，
自该文件创建以来的所有归档日志都存在，受到影响的文件不属于系统表空间或还原段表空间。
如果定期备份中不包含新的表空间或数据文件，或者该数据文件的备份丢失了，则通常使用该方法。使用ALTER DATABASE 命令，用相同的名称重新创建该数据文件：
SQL> ALTER DATABASE CREATE DATAFILE
2> '/ORADATA/u03/users01.dbf';
将使用数据字典中记录的原始文件名创建该文件。使用以下版本重新创建该数据文件，但使用新的文件名或位置：
SQL> ALTER DATABASE CREATE DATAFILE
2> '/ORADATA/u03/users01.dbf'
3> AS '/ORADATA/u04/users01.dbf';
查询V$RECOVER_FILE 确定恢复状态，以检查备份的状态：

1. 如果数据库已关闭，则装载该数据库、将该数据文件（无备份）脱机，然后打开数据库。这将允许不需要TABLE_DATA 表空间的用户对系统执行操作。
如果数据库已打开，则将该数据文件或表空间脱机。如果数据库已打开，则必须包含“立即” (IMMEDIATE) 选项，以避免数据库写入器试图写入到一个并不存在的文件中：
SQL> ALTER TABLESPACE table_data OFFLINE IMMEDIATE;
Tablespace altered.
查询V$RECOVER_FILE 确定恢复状态，以检查备份的状态：
SQL> SELECT * FROM v$recover_file;
2. 发出以下命令来重新创建该文件：
SQL> ALTER DATABASE create datafile ‘/disk2/DATA/df4.dbf’
2> as ‘/disk1/DATA/df4.dbf‘;
SQL> SELECT * FROM v$recover_file;
3. 用RECOVER 或ALTER DATABASE RECOVER 命令，开始将归档重做日志文件和联机
重做日志文件应用到重新创建的数据文件中：
SQL> RECOVER TABLESPACE table_data;
要将数据文件恢复到发生故障前的那一刻，应该应用所有需要的归档日志和重做日
志。此时所有数据文件都将实现同步。
4. 恢复完成后，将该表空间联机：
SQL> ALTER TABLESPACE table_data ONLINE;
所有数据现已恢复。将文件包括在备份策略中，并通知用户可以再次使用表空间了。

只读表空间恢复
情况1：被恢复的表空间现在是只读的，并且在上次备份时也是只读的。在这种情况下，只需从备份中还原表空间。无需应用任何重做信息。
情况2：被恢复的表空间现在可读写，但在上次备份时则是只读的。在这种情况下，需要从备份中还原表空间，并应用自表空间被设置为可读写状态以来的重做信息。
情况3：被恢复的表空间现在是只读的，但在上次备份时是可读写的。因为您应该在将表空间设置为只读状态后始终对它进行备份，所以不应该遇到这种情况。
但是，如果确实出现这种情况，则必须从备份中还原表空间，并将其恢复到被设置为只读状态前的那一刻。
如果您需要用CREATE CONTROL FILE 命令重新创建控制文件，并且您的数据库有只读表空间，则必须按照特殊的过程进行操作。发出ALTER DATABASE BACKUP CONTROLFILE TO TRACE 命令以获得这些过程的列表。
如果不能将只读数据表空间中的数据文件副本还原到正确的目标位置，则可以使用ALTER DATABASE RENAME 命令将这些文件放到新的位置。
带备份控制文件的只读表空间与脱机正常表空间的恢复过程实质上是相同的，只是您需要在打开数据库后将表空间联机。

丢失控制文件的恢复
以下是三种可能需要您恢复或重新创建控制文件的情形：
第一，所有控制文件由于某个故障而丢失。如果您已正确地多元备份了控制文件并将这些文件分布到多个物理设备上，则很少会遇到这种问题。
第二，您需要更改数据库的名称。如果数据库将成为分布式环境的一部分，并且其它数据库具有相同的名称，则有必要更改数据库的名称。如果是出于恢复目的而还原数据库，则可能也需要更改其名称。
第三，您需要更改控制文件中的设置。控制文件中的很多设置是在文件创建之时确定下来的。在创建了控制文件后，就不能动态地更改这些设置；若要更改这些设置，必须重新创建控制文件。
有三种方法可以用于还原和恢复控制文件：
第一，用当前副本还原丢失的文件。这种方法假定您没有丢失所有的控制文件。
第二，使用CREATE CONTROLFILE 命令创建一个新文件。要完成此项操作必须知道数据库的所有文件。间或备份控制文件以进行跟踪有助于完成此过程。
第三，使用RECOVER DATABASE USING BACKUP CONTROLFILE 命令。如果丢失了所有的控制文件，则需要使用此命令。
如果使用镜像的数据文件正确配置数据库，则丢失所有控制文件的可能性将降至最低。

不完全恢复
不完全恢复能够重建数据库，使之恢复到以前的某个时间点（发生故障之前）。该情况会导致进行恢复操作后提交的事务处理中丢失数据。
如果需要，这些数据将需要手动重新输入。只在绝对必要的情况下执行这种恢复操作。不完全恢复操作可能比较困难而且耗费时间较长。要执行不完全恢复，需要：
恢复时间点之前制作的所有数据文件的有效脱机或联机备份,截止到指定的恢复时间之前备份中生成的所有归档日志通常在完全恢复操作失败的情况下进行不完全恢复。
需要进行不完全恢复的常见情况：
丢失归档：由于归档日志损坏或丢失，完全恢复操作失败。数据库只能恢复到应用归档日志之前的过去的某一时间的状态。
丢失重做日志：未镜像重做日志，并且重做日志在归档之前丢失，数据文件也丢失。恢复无法继续到丢失的重做日志之后。
用户错误：用户错误地删除了某个表，提交了用错误的WHERE 子句更新的数据等等。
丢失控制文件：您未镜像控制文件，不知道数据库的结构，但您有旧的二进制副本的备份。
不完全恢复的类型：
基于时间的恢复，截止指定时间点之前的所有更改提交后，该恢复方法终止。
在以下情况下使用此方法：对数据作出了不必要的更改，或者删除了重要的表，并且知道错误发生的大概时间。
如果您立即得到通知，恢复时间最短、数据损失最少。精心测试过的程序、安全性和过程应当可以避免此类恢复。知道未镜像的联机重做日志损坏的大概时间。镜像日志可以避免此类恢复。
基于取消的恢复，在恢复提示符下输入CANCEL（而不是日志文件名），即可终止该恢复方法。在以下情况下使用此方法：当前重做日志文件或组被破坏，并且不可用于恢复。
镜像可以避免此类恢复。进行恢复所需的归档重做日志文件丢失。经常备份并将归档存放在多个目标位置可以避免此类恢复。
基于更改的恢复，截止指定系统更改编号(SCN) 之前所做的所有更改提交之后，该恢复方法即终止。在分布式环境中恢复数据库时，使用这种方法。
使用备份控制文件恢复，指定的恢复方法（基于取消、基于时间或基于更改的恢复）已完成或控制文件已恢复时，该恢复方法终止。
必须在RECOVER DATABASE 命令中指定恢复将使用控制文件的旧副本。在以下情况下使用这种方法：
所有控制文件都已丢失，并且无法重新创建，但存在控制文件的二进制备份。镜像控制
文件（至不同磁盘）并保留CREATE CONTROLFILE 语句的当前文本版本将减少使用该方法的几率。将某个结构与当前数据库不同的数据库还原到先前的某个时间点。

不完全恢复原则：
认真按照所有恢复步骤进行操作很重要，因为不完全恢复的大多数问题都是由恢复过程中的DBA 错误造成的。事务活动只能前滚至期望的时间，而不能回退至期望的时间。
这就是对要及时恢复的数据库必须还原所有数据文件的原因。如果没能还原所有数据文件，将无法打开（非同步）数据库。
开始不完全恢复之前应执行整体关闭数据库备份（包括控制文件和重做日志）。这样
做的好处有：允许从错误中恢复。如果恢复失败（例如，恢复超出了期望的恢复点），重做
日志和控制文件将无法用于下一次恢复，除非存在这些文件的备份。如果恢复失败，可以节省时间。在这种情况下，可以以从新备份中还原数据文件，而不是从需要应用归档的上一次备份中还原。
如果不执行整体备份，至少应归档当前重做日志(ALTER SYSTEM
ARCHIVE LOG CURRENT) 并备份控制文件(ALTER DATABASE BACKUP
CONTROLFILE TO <LOCATION>)。
恢复成功后，执行关闭的数据库的整体备份。如果需要进行恢复才能完成下一次排定的备份，则建议使用这种方法。
在允许用户访问系统之前一定要验证故障是否已经修复，以防止恢复失败而需要再次进行恢复。从系统中备份（以后删除）归档日志，以避免混合不同数据库复本中的归档。

不完全恢复的步骤
出现故障而要求进行不完全恢复时，必须拥有下列文件才能进行恢复：包含所有数据文件的有效脱机或联机备份。从上次还原的备份到发生故障之前的所有归档重做日志。
请按照下列步骤进行恢复：
1. 对现有数据库执行关闭的数据库的完全备份。关闭数据库，从备份还原所有数据
文件（包括系统表空间文件）。
2. 还原所有数据文件，以及时恢复数据库。
3. 将数据库置于装载模式并确保数据文件处于联机状态。
4. 恢复数据库。
5. 使用RESETLOGS 选项打开数据库并验证恢复。
6. 对数据库执行关闭的数据库的整体备份。
以下命令用于执行不完全恢复：
RECOVER [AUTOMATIC] DATABASE <Option>
其中：
automatic：自动应用归档和重做日志文件。
option: until time ‘YYYY-MM-DD:HH:MI:SS’
until cancel
until scn <integer>
using backup control file
注：要在恢复过程中自动应用重做日志文件，可以使用SQL*Plus 命令SET
AUTORECOVERY ON，在恢复提示符后输入AUTO，或者使用SQL 命令RECOVER
AUTOMATIC。

基于时间的恢复示例：
当前时间是2001 年3 月9 日夜间12:00。
EMPLOYEES 表已被删除。
删除该表的时间大约是上午11:45。
由于大多数员工当前都在开会，数据库的活动很少。该表必须进行恢复。 使用UNTIL TIME 进行不完全恢复：
关闭数据库并开始恢复。由于知道故障发生的大概时间，并且数据库结构从上午11:44 之后并未更改，因此，可以使用UNTIL TIME 方法：
1. 如果数据库已打开，使用NORMAL 或IMMEDIATE 或TRANSACTIONAL 选项关闭数据库。
2. 从备份还原所有数据文件（尽可能使用最新备份）。可能需要还原归档日志。
如果有足够的可用空间，还原到LOG_ARCHIVE_DEST 位置，或使用ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> 或SET LOGSOURCE <LOCATION> 更改位置。
3. 装载数据库。
4. 恢复数据库：
SQL> recover database until time ‘2001-03-09:11:44:00’
5. 要将数据文件与控制文件和重做日志同步，应使用RESETLOGS 选项打开数据库：
SQL> alter database open resetlogs;
SQL> archive log list
6. 执行关闭的数据库的整体备份之前，查询EMPLOYEES 表以确保该表存在。
恢复成功并且备份完成后，通知用户该数据库可以使用，而恢复时间（上午11:44）后输入的所有数据将需要重新输入。

基于取消的恢复示例：
当前时间是2001 年3 月9 日夜间12:00。
某人尝试修复损坏的块时删除了EMPLOYEES 表。
日志文件都位于同一磁盘上。
删除该表的时间大约是上午11:45。
员工当前正在开会。
您担心是磁盘错误导致EMPLOYEES 表中的块损坏。由于重做日志都包含在同一磁盘中，
您决定检查重做日志和归档日志的状态：
SQL> select * from v$logfile;
SQL> select * from v$log;
重做日志未多元备份。有一个联机重做日志缺失。缺失的重做日志未归档。重做日志包含自上午11:34 以来的信息。26 分钟的数据将丢失。用户可恢复其数据。
对/disk1/data 目录进行搜索之后，发现找不到重做日志log2a.rdo，并且该日志未归
档。因此，不能恢复该点之后的数据。
查询V$LOG_HISTORY 确认缺少归档日志序列48 (log2a.rdo)：
SQL> select * from v$log_history;
由于这是OLTP 系统，V$LOG 的输出显示：如果数据库是在应用log2a.rdo 之前恢复的，另外10 分钟的工作将丢失。用户不愿意丢失工作，但可以恢复该工作。可以以按照以下步骤恢复数据库：
1. 关闭数据库。
2. 从最新备份还原所有数据文件。
3. 您已经拥有有效备份，因此请装载数据库。
4. 将数据库恢复到序列号为48 的日志：
SQL> recover database until cancel
5. 使用RESETLOGS 选项打开数据库。
6. 检查EMPLOYEES 表是否存在。
7. 恢复完成后，制作一份备份。通知用户该数据库可以使用，而恢复时间（上午11:34）
之后输入的所有数据将需要重新输入。

恢复期间使用备份控制文件：
当前时间是2001 年3 月9 日夜间12:00。包含EMPLOYEES 表的表空间已被删除。错误出现的时间大约是上午11:45。许多员工记录都在这一天早晨更新，但上午11:00 之后没有更新。每天晚上都进行备份。
前一晚的备份包含恢复所需的数据文件和控制文件。EMP_TS 表空间有一个数据文件。当前日志序列号是61。确认该表空间是在2001 年3 月9 日上午11:44:54被删除的。数据文件编号4 处于脱机状态。
1. 包含EMPLOYEES 表的表空间已被删除，如下所示：
SQL> drop tablespace emp_ts including contents;
2. 您立即要求用户注销并保留过去15 分钟内输入的数据记录。在等待所有用户注销并且其余会话终止时，您将数据库置于受限模式以防止进一步的访问：
SQL> alter system enable restricted session;
3. 调查过程中，您从前一晚的备份中找到了二进制控制文件。由于当前的控制文件将被替换，因此应仔细收集数据库结构信息，以备不时之需：
SQL> select * from v$log;
4. 您通过检查警报日志确定错误发生时间：
5. 关闭数据库、备份控制文件、然后还原表空间存在时的某个时间点的数据库的所有数据文件和控制文件。尝试打开数据库之后，以下错误将通知您重做日志与控制文件不同步：
ORA-00314: log 1 of thread 1,expected sequence# doesn't match
ORA-00312: online log 1 thread 1: '/disk1/data/log1a.rdo'
6. 验证是否存在脱机数据文件并使它们处于联机状态，因为恢复后所有脱机文件可能无法恢复：
SQL> select * from v$recover_file;
SQL> alter database datafile 4 online;
7. 执行恢复：
SQL> recover database until time '2001-03-09:11:44:00'
2> using backup controlfile;
8. 要使数据文件与控制文件和重做日志同步，请用RESETLOGS 选项打开数据库。
9. 检查EMPLOYEES 表是否存在。
10. 进行整体备份。
11. 通知用户数据库可以使用，需要重新输入在上午11:44 之后输入的所有数据。

当前联机重做日志文件的丢失的恢复
当前联机重做日志丢失，如果数据库已经关闭：尝试打开数据库。查找当前日志序列号。恢复发出取消命令之前的数据库。如果需要，应删除并重新创建日志文件。使用RESETLOGS 打开数据库。执行整体数据库备份。
如果数据库关闭，可能发生了介质故障或者后台进程可能已终止。按照以下步骤纠正该情况：
1. 如果尝试打开数据库，以下消息将立即通知您当前的重做日志组：
Database mounted.
ORA-00313: open failed for members of log group 2 of
thread 1
ORA-00312: online log 2 thread 1: '/disk1/archive/log2a.rdo'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
由于日志组2 是当前日志组，因此尚未归档。使用CLEAR LOGFILE 命令无效，原因是：
SQL> alter database clear unarchived logfile group 2;
ORA-01624: log 2 needed for crash recovery of thread 1
ORA-00312: online log 2 thread 1: 'disk1/archive/log2a.rdo'
2. 因此需要不完全恢复。首先，必须记录当前日志序列号：
SQL> select * from v$log;
3. 从先前的备份还原所有数据文件，使用RECOVER UNTIL CANCEL 命令并在应用重做日志61 之前停止：
SQL> recover database until cancel;
4. 使用RESETLOGS 选项打开数据库。
5. 现在数据库应该可以运行了，因为将重新创建所有丢失的日志文件。
注：如果由于介质故障需要在另一个磁盘上重新创建日志文件，请使用ALTER
DATABASE DROP LOG GROUP 和ALTER DATABASE ADD LOG GROUP 命令手动创建日志文件。
6. 由于您刚刚执行了不完全恢复，因此，现在应备份数据库。

RMAN简介与配置
RMAN是自动管理的备份恢复。它功能强大，使用起来虽然比手动管理的备份恢复有些繁琐，但当你全部掌握RMAN的功能后就会发现，它其实是比手动管理的备份恢复要简单的。
还有值得称道的一点是，RMAN的操作性能要好于手动管理的备份恢复。 

RMAN备份恢复简介
RMAN 提供了一种灵活的方式来备份数据库、表空间、数据文件、控制文件和归档日志，因为灵活，所以有些繁琐。
RMAN有准备对坏块进行恢复的功能，这是手动管理的恢复所不具备的。RMAN可以只恢复数据文件中损毁的块。
RMAN 提供了一种灵活的方式来执行下列操作：
备份数据库、表空间、数据文件、控制文件和归档日志；存储频繁执行的备份和恢复操作；执行增量块级别备份跳过未使用的块，可以只备份自上次备份后发生更改的块。
这还可以减少在ARCHIVELOG 模式下执行恢复操作所需的时间；可以以使用RMAN 来管理备份片的大小，并通过并行化备份操作来节省时间；
RMAN 操作可以和操作系统的日程安排集成在一起，以实现自动备份操作；指定备份限制。
可以以检测块的损坏情况。可以使用V$BACKUP_CORRUPTION 和V$COPY_CORRUPTION 动态视图来获取有关在备份时检测到的块损坏的信息。 
RMAN 可以提高性能，例如：
自动并行化备份、还原和恢复操作，在联机数据库备份期间不生成额外的重做日志，为避免干扰OLTP 工作，
限制备份操作每一秒钟只对一个文件进行读取，应用多路复用技术，在保持磁带机流式处理的同时，防止任何一个文件读写溢流。
RMAN 包含一个介质管理API，可以与第三方介质管理工具一起无缝工作，使得这些工具可以与存储设备实现交互，从而提高速度和可靠性。
如果使用用户管理的方法，您需要跟踪所有数据库文件和备份。在执行恢复操作时，您必须找到每个数据文件的备份、使用操作系统命令将它们复制到正确位置，然后选择要应用的日志。
而RMAN 能够自动管理这些任务。RMAN 的这一优点在使用“Oracle 管理文件” (Oracle Managed Files) 时尤其有用。
恢复管理器具有命令行界面。Oracle Enterprise Manager 也为恢复管理器提供图形用户界面。在Oracle8 或更高版本的数据库上都可以使用恢复管理器。

服务器会话：由RMAN 调用的服务器进程(UNIX) 或线程(Windows NT) 与目标数据库连接，通过PL/SQL 接口执行备份、还原和恢复功能。
目标数据库：正在使用RMAN 对其进行备份和恢复操作的数据库称作目标数据库。目标数据库的控制文件包含其物理结构的有关信息，例如，数据文件的大小和位置、联机和归档重做日志文件以及控制文件。
在备份和恢复操作过程中，由RMAN 调用的服务器会话将使用这些信息。
RMAN 资料档案库：RMAN 在执行备份、还原和恢复操作时使用的数据称为RMAN 元数据。这些元数据存储在目标数据库的控制文件和可选的恢复目录数据库中。
尽管不是必须创建恢复目录才可以使用RMAN，但使用恢复目录却是有益的。恢复目录应放在目标数据库之外的另一数据库中。
通道：要执行并记录备份和恢复操作，RMAN 需要链接至目标数据库。该链接称为通道。可以手动分配通道，也可以使用自动通道分配功能预先配置通道。
介质管理库：介质管理库(MML) 由RMAN 在写入磁带或从磁带读取时使用。使用磁带介质所需的附加介质管理软件由介质和存储系统供应商提供。

RMAN配置

RMAN恢复目录和控制文件的用法
RMAN 在RMAN 资料档案库中存储有关目标数据库及其备份和恢复操作的信息。目标数据库控制文件可用作专门存储该信息的位置。
存储的信息量会根据备份频率、生成的归档重做日志文件的数量以及RMAN 记录的保留时间而增长。
CONTROL_FILE_RECORD_KEEP_TIME 参数指定RMAN 信息至少要在控制文件中存储多少天后才会被覆盖。该值越小，信息就会越频繁地被覆盖，从而尽可能减少控制文件的增长。
如果使用恢复目录，则应选择较小的数值。缺省值为7 天。
如果控制文件太小，不能存储由CONTROL_FILE_RECORD_KEEP_TIME 指定的时间段内的所有信息，那么控制文件将会增长。在控制文件增长之前，将执行以下的特定步骤：
1. 使用控制文件中的空闲空间。
2. 覆盖早于CONTROL_FILE_RECORD_KEEP_TIME 的条目。
3. 如果没有更多空间可用，控制文件将按需增长，直到达到操作文件大小的系统限制。

通道分配
每个通道代表通向某一类型设备的一个数据流。在执行备份和恢复命令前，必须先分配通道。每个已分配的通道建立从RMAN 可执行文件到目标或辅助数据库（通过复制命令建
立的数据库或TSPITR 中使用的临时数据库）例程的连接，方法是在例程上启动服务器会
话。该服务器会话执行备份和恢复操作。只有一个RMAN 会话可与已分配的服务器会话
通信。每个通道通常对应一个输出设备，除非您的MML 具有硬件多路复用功能。
可以以手动分配通道，也可以使用自动通道分配功能预先配置要在所有RMAN 会话中使用的通道。
手动分配通道时，可在RMAN 提示符下，将ALLOCATE CHANNEL 作为RUN 命令的子命令发出，也可使用ALLOCATE CHANNEL FOR MAINTENANCE 命令。手动通道分配将覆盖自动通道分配。
恢复管理器使用通道进程在Oracle 服务器与操作系统之间进行通信。系统将为每个分配的通道创建目标数据库的一个Oracle 服务器进程。
从恢复管理器发出的每个BACKUP、COPY、RESTORE 或RECOVER 命令至少需要一个通道。
分配的通道数将是备份、还原或恢复期间使用的最大并行度。所需的介质类型确定了分配的通道类型。查询V$BACKUP_DEVICE 视图可以确定支持哪些设备类型。
可以通过在ALLOCATE CHANNEL 命令中指定参数来对COPY 和BACKUP 命令施加限制：
Read rate：限制每个文件每秒读取的缓冲区数，防止过多的磁盘I/O 降低联机性能。allocate channel … rate = integer
Kbytes：限制通道创建的备份片文件大小。这在操作系统或设备类型有最大的文件大小限制时非常有用。allocate channel … maxpiecesize = integer。
MAXOPENFILE：限制大型备份时同时打开的文件数（缺省值为16）。该参数可以防止打开的文件过多。ALLOCATE CHANNEL … MAXOPENFILE = integer
分配通道示例：
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE disk;
此命令为DELETE 命令分配通道，因为将从磁盘删除一个文件。维护通道不能用于任
何其它I/O 操作，如备份或复制。
RMAN> RUN {
ALLOCATE CHANNEL d1 DEVICE TYPE disk
FORMAT = '/db01/BACKUP/%U’;
BACKUP DATAFILE ’/…/u03/users01.dbf';}
第二个示例分配一个名为d1 的通道，由该通道创建的所有文件都具有格式
’/db01/BACKUP/%U’。该通道备份一个数据文件/db01/ORADATA/u03/users01.dbf。

在Oracle9i 中，可以使用自动通道分配功能预先配置要在所有RMAN 会话中使用的通道。RMAN 提供一个预先配置的DISK 通道，可以将该通道用于备份数据和将数据复制到磁盘。
此外，您还可以配置一组永久的自动通道。可通过CONFIGURE CHANNEL 命令将自动通道指定给磁盘或磁带。
可在RMAN 资料档案库中保存永久配置信息，如通道参数、并行性和缺省设备类型。可配置自动通道用于备份、还原、恢复和维护作业。
如果通道是由RMAN 自动分配的，其名称格式为ora_devicetype_n（ora_sbt_tape_n 或ora_disk_n）。
如果未指定名称格式，在缺省情况下，RMAN 将使用%U 格式，该格式可保证标识符唯一。%U 指定%u_%p_%c 的简写方式，可保证生成的备份文件名的唯一性。
%u 指定一个8 个字符长的名称，该名称由备份集号和备份集创建时间的缩写形式构成。%p 指定备份集中的备份片号。%c 指定一组双重备份片中备份片的副本数。
可通过ALLOCATE CHANNEL 命令手动分配通道来覆盖自动通道。自动分配通道功能与手动分配通道功能是互斥的，即：对于每个作业，RMAN 要么使用自动分配，要么使用手动分配。
缺省情况下，RMAN 已预先配置了一个磁盘通道，这样可以以备份到磁盘而无需进行任何手动配置。因此，如果要备份到磁盘而不是介质管理器，现在就可以开始备份到磁盘。

介质管理
要使用磁带存储数据库备份，RMAN 需要使用介质管理器。介质管理器是加载、标记和卸载顺序介质的实用程序，如用于备份、还原和恢复数据的磁带机。
Oracle 服务器调用MML 软件例行程序将数据文件备份到由介质管理器控制的介质或从介质中还原数据文件。
有些介质管理产品可以管理Oracle 数据文件与备份设备之间的整个数据移动。有些产品在存储设备与介质子系统之间使用高速连接，从而大大降低主数据库服务器的备份负载。
注：如果是备份到磁盘，Oracle 服务器无需连接到介质管理库(MML) 软件。
Oracle 备份解决方案(Oracle Backup Solutions Program, BSP) 提供一系列符合Oracle的MML 规范的介质管理产品。
使用与MML 界面相兼容的软件，Oracle 服务器会话可备份到介质管理器并请求介质管理器还原备份。请与介质供应商联系以确定其是否为Oracle BSP 的成员。
在开始将RMAN 用于介质管理器之前，必须先安装介质管理器并确保RMAN 可与其进行通信。有关该过程的具体说明，请参见介质管理器供应商的软件文档。
根据要安装的产品，相应执行以下基本步骤：
1. 在目标主机或产品网络上安装并配置介质管理软件。此阶段无需集成RMAN。
2. 确保可在目标数据库主机上创建操作系统文件的非RMAN 备份。此步骤将使以后排除故障更为容易。请参阅介质管理文档以了解如何将文件备份到介质管理器。
3. 获取并安装要与Oracle 服务器集成的第三方介质管理模块。该模块必须包含Oracle
要在访问介质管理器时加载的库。安装介质管理软件后，介质管理库应已与Oracle 服务器集成在一起。下面的恢复管理器脚本可以将数据文件备份到由介质管理器控制的磁带机上：
run {
# Allocating a channel of type 'sbt' for serial device
ALLOCATE CHANNEL ch1 DEVICE TYPE 'sbt';
BACKUP DATAFILE 3;
}
恢复管理器执行该命令时，将向执行该备份操作的Oracle 服务器会话发送备份请求。Oracle 服务器会话将输出通道标识为介质管理设备，然后请求介质管理器装载磁带并将输出写入磁带。
介质管理器会标记并记录磁带以及磁带上每个文件的名称。介质管理器可处理还原和备份操作。还原文件时，将执行以下步骤：
1. Oracle 服务器请求还原某一特定文件。
2. 介质管理器标识包含该文件的磁带，并读取磁带。
3. 介质管理器将信息传回到Oracle 服务器会话。
4. Oracle 会话将文件写入磁盘。

与RMAN 连接的类型
使用恢复管理器，可连接到下列类型的数据库：
目标数据库：使用SYSDBA 权限连接到目标数据库。您必须具有该权限才能连接成功。
恢复目录数据库：这是一种为RMAN 资料档案库配置的可选数据库。
辅助数据库：辅助数据库是使用RMAN DUPLICATE 命令创建的数据库。它也可能是在表空间时间点恢复(TSPITR) 过程中使用的临时数据库。备用数据库是生产数据库的副本，可用于灾难恢复。

恢复管理器模式
恢复管理器是一个具有自己的命令语言的命令行解释程序(CLI)。RMAN 有两种操作模式：交互模式和批处理模式。
交互模式：要交互运行RMAN 命令，请启动RMAN，然后在命令行界面中键入命令。例如，可以从UNIX 命令shell 启动RMAN，然后执行以下交互命令：
$ rman target sys/sys_pwd@db1
RMAN> BACKUP DATABASE;
批处理模式：可以以将RMAN 命令输入到一个文件中，然后通过在命令行中指定该文件的名称来运行该命令文件。命令文件的内容应与命令行中输入的命令完全相同。
以批处理模式运行时，RMAN 从命令文件中读取输入内容，然后将输出消息写入日志文件（如果已指定）。
RMAN 在编译或执行任何命令前先对整个命令文件进行语法分析。无需在文件中添加退出命令，因为RMAN 将在到达文件末尾时终止执行。
批处理模式最适合于通过操作系统作业控制设备来执行安排好的定期备份操作。
$ rman target / @tbsbk.rcv log tbs.log
在该示例中，用户已经创建了文件tbsbk.rcv，该文件包含用户本要交互使用的命令。RMAN 会将消息输出到文件tbs.log。
使用“运行RMAN 脚本” 任务，所有可从RMAN 命令行调用的命令或脚本都可以通过Oracle Enterprise Manager 发出。在“参数” (Parameters) 页上，指定“运行RMAN 脚本” 任务的参数设置。

RMAN命令与参数
将RMAN 输出写入到一个日志文件：
$ rman target sys/oracle
log $HOME/ORADATA/u03/rman.log append
调用RMAN 时执行命令文件：
$ rman target sys/oracle
log $HOME/ORADATA/u03/rman.log append
@'$HOME/STUDENT/LABS/my_rman_script.rcv'
LOG = 'filename' 参数指定用于记录RMAN 输出的文件。如果未指定该参数，
RMAN 将把其消息日志文件写入到标准输出。如果无法打开指定的文件，RMAN 不会中止，而是将输出内容写入到标准输出设备。
APPEND 关键字指定新的输出应附加在消息日志文件的末尾。如果未指定该参数，一旦存在与消息日志文件同名的文件，RMAN 将覆盖该文件。
可使用CMDFILE = 'filename' 运行包含RMAN 命令的文件。如果文件名的第一个字符是字母，则可不必将文件名放在引号内。RMAN 将在运行命令文件后终止。
RMAN 具有两种基本类型的命令：独立命令和作业命令。独立命令在RMAN 提示符下执行，通常是自包含的。下列是部分独立命令：
CHANGE、CONNECT、CREATE CATALOG, RESYNC CATALOG、CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT。
作业命令通常被分成几组，由RMAN 在RUN 命令块内按顺序执行。如果块内任何一个命令失败，RMAN 将停止处理；而不再继续执行块内的其它命令。
有一些命令既可在提示符下发出也可在RUN 命令中发出。如果在RMAN 提示符下执行独立命令，可利用自动分配通道的功能。可以按交互模式或批处理模式执行命令。
独立命令示例：
装载目标数据库
发出启动命令，如下所示：
RMAN> STARTUP MOUNT
关闭目标数据库
发出关闭命令，如下所示：
RMAN> SHUTDOWN IMMEDIATE
列出目标数据库的当前配置
使用REPORT 命令获取数据库的配置信息，如下所示：
RMAN> REPORT SCHEMA;
作业命令示例：
RMAN> RUN {
backup
incremental level 0
format ‘/u01/db01/backup/%d_%s_%p’
fileperset 5
(database include current controlfile);
sql ‘alter database archive log current’;
}
与独立命令不同，作业命令必须包含在RUN 命令的括号中。下面是作业命令的示例：
ALLOCATE CHANNEL、SWITCH
RMAN 按顺序执行RUN 命令块内的作业命令。如果块内的任何命令失败，RMAN 将停止处理；不再继续执行块内的其它命令。
实际上，RUN 命令定义了一个命令执行单位。当RUN 命令块内的最后一个命令执行完毕后，Oracle 将释放为该命令块分配的所有服务器端资源，如I/O 缓冲区或I/O 从属进程。

配置RMAN 环境
RMAN 预设为使用适用于所有RMAN 会话的缺省配置设置。可以使用CONFIGURE 命令配置RMAN 备份、还原、复制和维护作业的永久设置。这些设置将对所有RMAN 会话有效，除非清除或更改该配置。
使用Oracle Enterprise Manager，可以使用“创建备份配置” 向导来设置备份和恢复的缺省值。
使用CONFIGURE 命令可以：配置自动通道、指定备份保留策略、指定要创建的备份副本数、限制备份集的大小、使表空间从备份中脱离、启用和禁用备份优化。
CONFIGURE 命令示例：配置自动通道，使用CONFIGURE CHANNEL 命令可指定缺省备份位置和文件命名约定。
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/db01/BACKUP/%U';
配置备份保留策略，使用CONFIGURE RETENTION POLICY 命令可创建永久和自动的备份保留策略。RMAN 将根据您用CONFIGURE 命令指定的标准来确定数据文件和控制文件的备份和副本何时过期；
即，何时介质恢复不再需要使用这些备份和副本。可以发出REPORTOBSOLETE 命令查看已过期的文件，并使用DELETE OBSOLETE 命令将它们删除。发出
CONFIGURE RETENTION POLICY CLEAR 命令可将该设置恢复为缺省值。
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 days;
可以使用以下两种互斥方法中的任意一种来实施保留策略：
指定一个恢复期，该恢复期是从当前时间回溯到可恢复时间点的时间段。在以上示例中，使用CONFIGURE 命令可确保对每个数据文件都保留一份早于可恢复点（七天）的备份。
指定一个冗余值，该值指示备份或副本一旦超过某一指定数目，将不再予以保留。缺省情况下，RETENTION POLICY 配置为REDUNDANCY 1。
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
配置双重备份集：
对于使用自动通道的所有备份命令，可在一个备份集中为每个备份片最多创建四个副本。这仅适用于数据文件和归档重做日志文件。
RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE disk TO 2;
配置备份优化：
设置备份优化的目的是：如果相同的文件已备份到某一设备类型，BACKUP 命令不再将文件备份到该设备类型。两个文件相同，指的是其内容必须完全相同。
备份优化的缺省值是OFF。可以通过使用BACKUP 命令的FORCE 选项覆盖备份优化设置。
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
使用CLEAR 选项恢复为缺省值
RMAN> CONFIGURE RETENTION POLICY CLEAR;
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt CLEAR;
SHOW 命令用于显示使用CONFIGURE 命令指定的永久配置设置。配置的这些设置将用于任意RMAN 会话。
可以使用SHOW 命令显示下列信息：
自动通道配置设置：
SHOW CHANNEL;
SHOW DEVICE TYPE;
SHOW DEFAULT DEVICE TYPE;
RMAN 保留策略配置设置：
SHOW RETENTION POLICY;
备份副本数：
SHOW DATAFILE BACKUP COPIES;
备份集的最大大小：
SHOW MAXSETSIZE;
不包括在整个数据库备份中的表空间：
SHOW EXCLUDE;
备份优化的状态：
SHOW BACKUP OPTIMIZATION;
LIST 命令用于生成详细报告，列出下各项的所有信息：
包含指定的一系列数据文件的备份的备份集，指定的一系列数据文件的副本，包含属于指定表空间列表的任何数据文件的备份的备份集，属于指定表空间列表的任何数据文件的副本，
包含任何具有指定名称或范围的归档日志的备份的备份集，任何具有指定名称或范围的归档日志的副本。
使用此命令时必须连接至目标数据库。如果在NOCATALOG 模式下进行连接，则必须装载数据库。如果使用恢复目录进行连接，则必须启动目标例程（但无需装载）。
列出数据库备份，可以使用此命令生成数据库中所有文件的备份的列表：
RMAN> LIST BACKUP OF DATABASE;
列出备份集，上面的示例使用LIST 命令列出数据文件“/db01 /ORADATA/ u03/ users01.dbf”的所有已知备份。
RMAN> LIST BACKUP OF DATAFILE“/db01/ORADATA/u03/users01.dbf”;
列出数据文件副本，上面的示例使用LIST 命令列出SYSTEM 表空间的数据文件副本。
RMAN> LIST COPY OF TABLESPACE “SYSTEM”;
REPORT 命令，该命令有助于更详细地分析RMAN 资料档案库中的信息。
可以针对各种问题生成报告，该数据库的结构是怎样的？
RMAN> REPORT SCHEMA;
哪些文件需要备份？
RMAN> REPORT NEED BACKUP ...;
哪些备份可以删除（即已过期）？
RMAN> REPORT OBSOLETE;
哪些文件由于不可恢复的操作而不可恢复？
RMAN> REPORT UNRECOVERABLE ...;
REPORT NEED BACKUP 命令用于标识所有需要备份的数据文件。该报告假定在还原时使用最新的备份。该命令有三个选项：
增量(Incremental)：是一个整数值，指定应在恢复过程中还原的增量备份的最大数目。如果需要该数目或更多的增量备份，则需要对数据文件执行新的完全备份。
例如，要报告需要三个或更多增量备份才能进行恢复的文件：
RMAN > REPORT NEED BACKUP incremental 3 database;
天数(Days)：是一个整数值，指定距文件上一次完全或增量备份操作的最大天数。如果最近一次备份到当前的天数等于或超过该数字，则需要对该文件进行备份。
例如，报告三天未备份的系统文件：RMAN > REPORT NEED BACKUP days 3 tablespace system;
冗余(Redundancy)：一个整数值，指定必要的最低冗余级别。例如，如果没有两个或更多备份，则冗余级别2 将要求进行备份。

使用RMAN的注意事项
在使用恢复管理器之前，请考虑以下几点：
系统的共享资源：RMAN 的大多数工作是通过Oracle 服务器进程执行的。这些操作也
可以并行进行，以提高吞吐量。这意味着PROCESSES 参数必须足够高。从OS 的角
度看，这就意味着应该把共享内存和信号量设置得足够多。
执行授权操作的用户组：您必须确定执行授权操作的用户组。可以以相应地设置用户
帐户，使之具备必要的操作系统和Oracle 数据库权限。
要启动和关闭数据库，用户应具有SYSDBA 权限。
远程操作：您需要使用口令文件通过Oracle Net 连接到目标数据库，以执行授权的操作。例如，从远程计算机执行关闭、启动、备份和恢复操作。这样您就需要设置口令文件，还应确保具有备份该口令文件的策略。
全球化环境变量：调用RMAN 之前，设置NLS_DATE_FORMAT 和NLS_LANG 环境变量。这些变量确定RMAN 命令（如RESTORE、RECOVER 和REPORT）中的时间参数
的格式。
使用恢复目录：如果使用恢复目录，RMAN 可以执行更多种类的自动备份和恢复功能。使用恢复目录会涉及存储空间和维护方面的工作。
您还应确定是否将一个数据库专用于维护多个目标数据库的恢复目录。另外，还要考虑备份该恢复目录的策略。

RMAN备份
RMAN，全称是恢复管理器，它的备份性能要比手动的复制文件好一些。而且RMAN提供了增量备份的功能，是手动备份所不具备的。
RMAN针对数据文件的备份方式，主要有两种，一种就是增量备份，还有一种是映像拷贝。映像拷贝其实相当于手动的复制文件。

恢复管理器备份的概念
恢复管理器备份是由服务器管理的备份，恢复管理器使用Oracle 服务器会话执行备份操作恢复管理器提供对以下内容进行备份的功能：
整个数据库、表空间中的每个数据文件或单个数据文件、控制文件、所有归档日志或所选归档日志。使用恢复管理器时不备份联机重做日志文件。
关闭的数据库的备份：
关闭的数据库的备份定义为在数据库关闭（脱机）时进行的备份。这与一致数据库备份相同。如果执行关闭的数据库的备份，则不得打开目标数据库。如果使用恢复目录，则必须
打开恢复目录数据库。
打开的数据库的备份：
打开的数据库的备份定义为在数据库打开（联机）时对数据库任意部分进行的备份。恢复管理器使用服务器进程制作数据文件、控制文件或归档日志的副本。使用恢复管理器时，
不要使用ALTER TABLESPACE ... BEGIN BACKUP 命令将表空间置于备份模式。RMAN 读取块，直到获得一致读取为止。

确定RMAN特定的备份类型
可以使用恢复管理器执行以下类型的备份：
映像副本是数据文件、控制文件或归档重做日志文件的副本。可以使用恢复管理器或操作系统实用程序制作相应的副本。
数据文件的映像副本包含所有的数据文件块，其中包括未使用过的块。映像副本只能包含一个文件，而且不能对单个复制操作进行多元备份。
备份集可以包含一个或多个数据文件、控制文件或归档重做日志文件。备份集可以包
含一个或多个文件。可以使用两种完全不同的方法制作备份集：
完全备份：在完全备份中，可以备份一个或多个文件。在完全备份中，所有包含指定文件数据的数据块都会被备份。
增量备份：增量备份只对上次增量备份以后数据块有更改的数据文件进行备份。增量备份需要一个基础级别（即增量级别0）备份，该备份包含指定文件数据的所有块。
增量级别0 和完全备份均复制数据文件中的所有块，但是在增量备份策略中不能使用完全备份。
可以以配置自动备份控制文件，在执行BACKUP 或COPY 命令后即可自动备份控制文件。

使用RMAN BACKUP 命令创建备份集
备份集包含一个或多个物理文件（以RMAN 特定的格式存储在磁盘或磁带上）。可以制作包含数据文件、控制文件以及归档重做日志文件的备份集。也可以对备份集进行备份。
备份集有两种类型：
数据文件：可以包含数据文件和控制文件，但不包含归档日志
归档日志：仅包含归档日志，不能包含数据文件或控制文件
在执行恢复之前，可能需要通过恢复管理器还原备份集，这与磁盘上的映像副本不同。
备份集中的每个文件必须具有相同的Oracle 块大小。如果包含控制文件，就会将它写入到最后一个数据文件备份集中。可以使用以下两种方式将控制文件包含在备份集中：
使用INCLUDE CONTROL FILE 语法显式包含、通过备份文件1（系统数据文件）隐式包含。RMAN BACKUP 命令用于备份数据文件、归档重做日志文件以及控制文件。
BACKUP 命令将文件备份到磁盘或磁带上的一个或多个备份集中。在数据库打开或关闭时，都可以制作备份。制作类型既可以是完全备份，也可以是增量备份。

备份集是一种逻辑结构，它具有以下特性：
备份集包含一个或多个称作备份片的物理文件。备份集是使用BACKUP 命令创建的。FILESPERSET 参数可以控制备份集中包含的数据文件个数。可以将备份集写入磁盘或磁带。
缺省情况下，Oracle 为大多数平台提供一个磁带输出，称为SBT（系统备份到磁带），当使用介质管理器时，备份将输出到磁带设备中。
在执行恢复之前必须通过还原操作从备份集中提取文件。归档重做日志文件备份集不能是增量备份（缺省为完全备份）。备份集不包含从未使用过的数据块。
备份片是备份集中的一个文件。备份片可以包含来自多个数据文件的数据块。
逻辑备份集通常只包含一个备份片。备份片是一个包含一个或多个Oracle 数据文件或归档日志的物理文件。
对于大型数据库，一个备份集可能超出单个磁带盘、物理磁盘或操作系统文件的最大容量。
可以使用CONFIGURE CHANNEL 或ALLOCATE CHANNEL 命令及MAXPIECESIZE 选项来限制每个备份集片的大小。
可以使用以下命令限制备份片的大小，并根据需要为每个备份集生成多个片：
ALLOCATE CHANNEL … MAXPIECESIZE = integer
CONFIGURE CHANNEL … MAXPIECESIZE = integer
下面的例子限制备份片的大小：
RMAN> RUN {
2> ALLOCATE CHANNEL t1 TYPE 'SBT'
3> MAXPIECESIZE = 4G;
4> BACKUP
5> FORMAT 'df_%t_%s_%p' FILESPERSET 3
6> (tablespace users); }
可以控制Oracle 生成的备份集数以及恢复管理器在单个备份集中放置的输入文件数。如果在读取文件或写入备份片时出现I/O 错误，该作业就会中止。在使用BACKUP 命令时，必须执行以下操作：
装载或打开目标数据库。如果数据库处于ARCHIVELOG 模式，恢复管理器允许您制
作不一致备份，但您必须应用重做日志，使备份在恢复操作中使用时保持一致。
如果未使用自动通道分配，则手动分配一个通道用以执行BACKUP 命令。或者，可以执行下列操作：
指定备份片的命名约定。如果没有指定FORMAT 参数，则RMAN 将备份片存储在端口特定的目录中（在UNIX 上为$ORACLE_HOME/dbs）。如果没有指定文件名格式，则RMAN 缺省使用%U。
通过使用INCLUDE CURRENT CONTROLFILE 选项，可以将控制文件包含在备份集中。
借助RMAN 多元备份技术可同时读取磁盘上的文件，然后将这些文件写入同一个备份片。
在将多个文件写入同一备份文件或备份片时，恢复管理器自动将文件分配给通道、对这些文件进行多元备份，并且跳过所有未使用过的块。
为了同时备份足够多数量的文件，可以对高性能顺序输出设备（如快速磁带机）进行流式处理。这对于必须与其它联机系统资源
竞争的备份来说是很重要的。操作员或存储子系统负责更换磁带机所在目标数据库上的磁
带。该进程是为写入磁带设计的，但也可以将它用于写入磁盘。多元备份是由以下参数控制的：BACKUP 命令的FILESPERSET 参数，ALLOCATE CHANNEL 和CONFIGURE CHANNEL 命令的MAXOPENFILES 参数。
数据库包含三个数据文件，可以将这些数据文件一起多元备份到一个物理文件（集）中，
并存储在磁带上。数据文件是通过以下方式进行多元备份的：依次写入数据文件1、数据文件2、数据文件3 的各n 个块，然后又回到数据文件1 继续写，如此循环反复直至所有
文件备份完毕。

可以将CONFIGURE 命令的PARALLELISM 选项设置为大于1 或者手动分配多个通道来配置并行备份，RMAN 并行地执行其操作，并且并行地写入多个备份集。服务器会话负责分摊指定文件的备份工作。示例：
RMAN> run {
2> allocate channel c1 type sbt;
3> allocate channel c2 type sbt;
4> allocate channel c3 type sbt;
5> backup
6> incremental level = 0
7> format '/disk1/backup/df_%d_%s_%p.bak‘
8> (datafile 1,4,5 channel c1 tag=DF1)
9> (datafile 2,3,9 channel c2 tag=DF2)
10> (datafile 6,7,8 channel c3 tag=DF3);
11> alter system archive log current;
12> }

当创建多个备份集并分配多个通道时，RMAN 自动并行地执行其操作，并且并行地写入多个备份集。
分配的服务器会话负责分摊指定数据文件、控制文件和归档重做日志文件的备份工作。注意，不能让单个备份集分跨多个通道。
备份集的并行化通过以下方式完成：将PARALLELISM 配置为大于1，或者分配多个通道指定多个要备份的文件。示例：
有9 个文件需要备份（数据文件1 到9）。已经合理分配了数据文件，从而保证每个集要备份的数据块数大致相等（为了提高效率）。
将数据文件1、4 和5 分配给备份集1。
将数据文件2、3 和9 分配给备份集2。
将数据文件6、7 和8 分配给备份集3。
可以使用FILESPERSET 参数限制备份集中包含的数据文件个数。
通过对备份集进行双重备份，可以给每个备份片最多创建4 个完全相同的副本。可以使用以下命令生成双重备份的备份集：
BACKUP COPIES、SET BACKUP COPIES、CONFIGURE … BACKUP COPIES
RMAN 并不生成多个备份集，而是给集内的每个备份片生成完全相同的副本。示例：
此示例显示如何给数据文件1 和2 的备份创建两个副本：
RMAN> BACKUP COPIES 2 DATAFILE 1, DATAFILE 2
2> FORMAT '/BACKUP1/%U','/BACKUP2/%U';
RMAN 将每个备份片的第一个副本放入/BACKUP1，而将第二个副本放入/BACKUP2。RMAN 使用唯一键生成一个备份集，并给集内的每个备份片生成两个完全相同的副本。
另一种管理备份的方法就是对备份集进行备份。可以使用RMAN BACKUP BACKUPSET命令进行磁盘到磁盘以及磁盘到磁带的备份。这可用于在磁带上制作额外的备份，或者将备份从磁盘移到磁带上。

备份控制文件
如果CONFIGURE CONTROLFILE AUTOBACKUP 设置为ON，则在以下情况下，RMAN自动执行控制文件的自动备份：
在RMAN 提示符下执行每个BACKUP 或COPY 命令后，当RUN 命令块中BACKUP 或COPY 命令后跟的既不是BACKUP 也不是COPY 时，当每个RUN 命令块结尾处的最后一条命令既不是BACKUP 也不是COPY 时。
在执行这些命令过程中，除了执行当前控制文件的备份或复制外，还进行控制文件的自动备份。缺省情况下，CONFIGURE CONTROLFILE AUTOBACKUP 设置为OFF。
RMAN 使用%F 这种缺省格式自动备份当前的控制文件。可以使用CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT 和SET CONTROLFILE AUTOBACKUP FORMAT命令更改此格式。
格式字符串必须包含%F 替代变量。此变量将转换为c-IIIIIIIIII-YYYYMMDD-QQ，其中：
IIIIIIIIII 代表DBID。DBID 以十进制输出，因此可以方便地将它与目标数据库关联
起来。
YYYYMMDD 是生成备份当天的公历时间戳
QQ 是序列号（十六进制数字），从00 开始，最大值为'FF' (256)
示例：
RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE disk TO 'controlfile_%F';

备份归档重做日志文件
在开始执行每个不包含UNTIL 子句或SEQUENCE 参数的BACKUP ... ARCHIVELOG 命令时，RMAN 会尝试自动切换并归档当前的联机重做日志。
在Oracle9i 中，RMAN 执行归档日志故障转移。如果在归档重做日志文件中检测到任何损坏的块，RMAN 就会在其它归档目标中搜索没有损坏块的文件。
DBA 经常遇到的一个问题是：在备份归档日志之前，不知道是否已将其完全复制到归档日志目标中。
恢复管理器可以访问控制文件或恢复目录信息，所以它知道哪些日志已经归档，可以在恢复过程中还原。
可以使用BACKUP ARCHIVELOG 命令备份归档重做日志文件，或者在备份数据文件和控制文件时使用BACKUP … PLUS ARCHIVELOG 命令也同时备份这些日志文件。
归档日志备份集仅包含归档日志，不能包含数据文件或控制文件。始终是完全备份。（因为可以指定要备份的归档日志的范围，所以无法执行增量备份。）
下面的例子将所有的归档重做日志备份到一个备份集中，其中每个备份片包含3 个归档日志。在归档日志复制完毕后，将这些日志从磁盘上删除，并在V$ARCHIVED_LOG 视图中将它们标记为已删除。
RMAN> BACKUP
2> FORMAT '/disk1/backup/ar_%t_%s_%p'
3> ARCHIVELOG ALL DELETE ALL INPUT;

RMAN备份的要求
在使用恢复管理器执行备份时，必须注意以下几点：
恢复管理器要连接的目标数据库必须已装载。不支持对联机重做日志进行备份。
如果目标数据库处于NOARCHIVELOG 模式，则只能采用“干净的” 表空间和数据文件备份（即“脱机正常” 或“只读” 表空间的备份）。
要采用数据库备份，必须先彻底关闭该数据库，再以“装载” 模式重新启动它。
如果目标数据库处于ARCHIVELOG 模式，则只能备份“当前的” 数据文件（通过恢复将数据文件还原为当前状态）。
如果使用恢复目录，则必须打开恢复目录数据库。

使用RMAN COPY命令创建映象副本
RMAN映象副本和使用CP、COPY等操作系统命令复制文件没有什么区别。
在创建映象副本过程中，RMAN可以使用校验和来检查数据文件中块是否损坏。

映像副本包含单个数据文件、归档重做日志文件或控制文件。可以使用RMAN COPY 命令或操作系统命令创建映像副本。
当使用RMAN COPY 命令创建映像副本时，服务器会话验证文件中的块，并将副本记录到控制文件中。

RMAN映像副本的特性
映像副本具有以下特性：
只能将映像副本写入磁盘。因而，要在磁盘上保留该副本，则需要额外的磁盘空间。
对于大文件，复制花费的时间很长，但还原时间大大减少，这是由于该副本已经存在于磁盘上的缘故。
如果文件存储在磁盘上，则可以立即使用这些文件（也就是说，这些文件不需要从其
它介质还原）。这为在恢复管理器中使用SWITCH 命令进行恢复提供了一种快速方
法，它相当于ALTER DATABASE RENAME FILE SQL 语句。
映像副本中将包含所有的块（不管这些块是否包含数据），原因是Oracle 服务器进程在复制该文件的同时还会执行其它操作，
如检查损坏的块、在控制文件中注册该副本等。要加快复制进程，可以使用NOCHECKSUM 参数。
映像副本可以是完全备份或增量0 级备份的一部分，原因是文件副本总是包含所有块。如果该副本将与增量备份集一同使用，则使用0 级选项。
在增量备份策略中，可以将映像副本指定为0 级备份，但映像副本不能作为其它级别的备份。
使用RMAN COPY 命令可以创建文件的映像副本。输出文件始终写入磁盘。可以复制数据文件、归档重做日志文件或控制文件。
在很多情况下，复制数据文件比备份这些文件更有益处，原因是复制的数据文件输出不需要任何其它处理就可以使用。
如果要使用COPY 命令备份整个数据库，必须使用单独的COPY 语句复制每个数据文件。也可以制作控制文件和归档重做日志文件的副本。
下面的示例假定您使用的是自动通道分配。如果手动分配通道，则在RUN 语句中包含COPY 命令（如下所示）：
RMAN > RUN {
2> ALLOCATE CHANNEL c1 type disk;
3> COPY
4> DATAFILE '/ORADATA/users_01_db01.dbf' to
5> '/BACKUP/users01.dbf' tag=DF3,
6> ARCHIVELOG 'arch_1060.arc' to
7> 'arch_1060.bak';}

使用RMAN COPY 命令创建映像副本
在复制操作中，Oracle 服务器进程对每个块执行校验和计算以检测是否有块损坏。RMAN在还原副本时也要核对校验和。
该过程称为物理损坏检测。可以使用NOCHECKSUM 选项取消校验和操作，从而加快复制进程。如果数据库已在维护块校验和，则此选项无效。
可以使用CHECK LOGICAL 选项测试通过了物理损坏检查的数据和索引块，查看它们是否存在逻辑损坏，如行片或索引条目损坏。如果检测到任何块存在逻辑损坏，则将该块记录到服务器进程的警报日志和跟踪文件中。
可以使用MAXCORRUPT 参数设置逻辑和物理损坏的阈值。只要在某个文件中检测到的逻辑和物理损坏总和低于该值，则RMAN 命令完成，
同时Oracle 将损坏块的范围植入到V$COPY_CORRUPTION 视图。如果超出MAXCORRUPT，则该命令终止，并且不植入视图。
缺省情况下，恢复管理器将连续执行各COPY 命令。然而，可以通过以下方法并行执行复制操作：
使用CONFIGURE DEVICE TYPE … PARALLELISM，或分配多个通道（在Oracle8i 中是必需的），为多个文件指定一条COPY 命令，可以手动分配通道（如幻灯片所示），或者通过自动通道配置进行分配。
在下面的示例中，总共创建了4 个通道，但仅使用其中的3 个。以下是命令的执行情况：
1. 将4 个通道配置为写入磁盘。
2. 第一条COPY 命令使用3 个通道（服务器进程），一个数据文件通过一个通道写入磁盘。
3. 第二条COPY 命令将在前一条COPY 命令执行完成后才开始执行。它将只使用一个通道。当并行度比较高时，占用的计算机资源较多，但备份操作完成速度较快。

RMAN> CONFIGURE DEVICE TYPE disk parallelism 4;
2> COPY # 3 files copied in parallel
3> datafile 1 TO '/BACKUP/df1.dbf',
4> datafile 2 TO '/BACKUP/df2.dbf',
5> datafile 3 TO '/BACKUP/df3.dbf';
RMAN> COPY # Second copy command
2> datafile 4 TO '/BACKUP/df4.dbf';
要使用恢复管理器制作所有数据文件的映像副本，请按照以下步骤执行：
1. 连接到RMAN 并在装载模式下启动：
RMAN> STARTUP MOUNT
2. 获取目标数据库的数据文件列表：
RMAN> REPORT SCHEMA;
3. 使用COPY 命令或脚本创建上面列出的所有数据文件的副本：
RMAN> COPY datafile 1 TO ’/BACKUP/df1.cpy’,
datafile 2 TO ’/BACKUP/df2.cpy ’,...;
4. 使用LIST COPY 命令验证副本：
RMAN> LIST COPY;
可以使用CURRENT CONTROLFILE 命令将控制文件包含在副本中。此外，如果CONFIGURE CONTROLFILE AUTOBACKUP 为ON，则在执行COPY 命令后，RMAN 将自动备份控制文件。

RMAN备份类型
RMAN备份分为完全备份和增量备份，增量备份分为差异增量备份和累计增量备份。
完全备份
完全备份与整体数据库备份不同。整体备份包含目标数据库的所有数据文件和控制文件，而完全备份可能只包含一个或多个数据文件、控制文件或归档重做日志文件。
在执行完全备份时，Oracle 服务器进程读取整个文件，并将所有的块复制到备份集内，只跳过从未使用过的数据文件块。在备份归档重做日志或控制文件时，服务器会话不会跳过任何块。
完全备份不属于增量备份策略的一部分。可以用它创建和还原数据文件、数据文件副本、表空间、数据库、控制文件、归档日志和归档日志副本的完全备份。注意，包含归档重做日志的备份集始终是完全备份。

差异增量备份
这是增量备份的缺省类型，它备份自最近n 级或更低级别备份以来更改过的所有块。
您要维护一个100 GB 的数据库，该数据库还在不断地增长。基于现有的硬件，您确定执行打开的数据库的整体备份需要4 个小时。
由于数据库每周7 天、每天24 小时总是处于联机状态，所以在该时间段内执行备份将消耗大量系统资源。
因此，每周只能执行一次0级备份，但出现故障时必须进行快速恢复。综合考虑，您制订了以下备份和恢复策略：
0 级备份将在每周中活动最少的一天执行。您确定这一天为星期日。
RMAN> BACKUP INCREMENTAL level 0 database;
每天执行一次2 级增量备份，星期三除外。以这种方式备份的速度比较快，这是因为
只复制了自前一天以来更改过的块：
RMAN> BACKUP INCREMENTAL level 2 database;
星期三的数据库活动较少，所以在这一天复制自星期日以来更改过的所有块，以加快恢复速度。例如，如果在星期五发生故障，则只需要还原星期日、星期三和星期四的备份（不需要还原星期一和星期二的备份）：
RMAN> BACKUP INCREMENTAL level 1 database;
在星期四，增量备份被完全备份代替。由于这并不改变备份的基础级别，所以星期五的备份复制自星期三以来的更改。因此，可以在下一个0 级备份之前丢弃该备份。
如果错误地在星期四执行了0 级备份，则星期五的备份将复制自星期四以来更改过的所有块，这样就更新了基础级别。此时，必须将该备份保存到下一个0 级备份。

累计增量备份
备份自最近n-1 级或更低级别备份以来更改过的所有块。
累积增量备份具有以下特性：
累积增量n 级（其中，n > 0）备份复制自上次n-1 级或更低级别备份以来更改过的所有块。累积增量备份以相同的级别备份上次备份的块。
因此，与非累积备份相比，它们占用的时间较长、写出的块较多、生成的备份文件也较大。因为恢复时在各级别必须应用的备份较少，所以累积增量备份可以提高恢复速度。
累积增量备份以相同的级别复制上次增量备份已复制的更改。因此，如果采用2 级增量备份，则随后的2 级累积备份将备份所有新修改的块以及该2 级增量备份备份过的块。
这意味着要进行完全恢复，只需要一个同级的增量备份即可。
RMAN> BACKUP INCREMENTAL level 2 cumulative database;

在NOARCHIVELOG 模式下进行备份
1. 确保要存储备份的目标目录可用并具有足够的空间。
2. 使用NORMAL、IMMEDIATE 或TRANSACTIONAL 子句彻底关闭数据库。
3. 装载数据库。
4. 如果未使用自动通道分配，请分配多个通道，并使用格式字符串将通道多路复用
到不同的磁盘上。
5. 运行BACKUP 命令。由于数据库处于NOARCHIVELOG 模式，增量备份不适用，
请使用完全备份选项。
6. 确认备份完成并已分类。
7. 打开数据库进行正常使用。

自动备份RMAN 控制文件
如果CONFIGURE CONTROLFILE AUTOBACKUP 设置为ON，则在以下情况下，RMAN自动执行控制文件的自动备份：
在RMAN 提示符下执行每个BACKUP 或COPY 命令后，当RUN 命令块中BACKUP 或COPY 命令后跟的既不是BACKUP 也不是COPY 时，当每个RUN 命令块结尾处的最后一条命令既不是BACKUP 也不是COPY 时。
在执行这些命令过程中，除了执行当前控制文件的备份或复制外，还进行控制文件的自动备份。
缺省情况下，CONFIGURE CONTROLFILE AUTOBACKUP 设置为OFF。
RMAN 使用%F 这种缺省格式自动备份当前的控制文件。可以使用CONFIGURE CONTROLFILE AUTOBACKUP FORMAT 和SET CONTROLFILE AUTOBACKUP FORMAT。
格式字符串必须包含%F 替代变量。此变量将转换为c-IIIIIIIIII-YYYYMMDD-QQ，其中：
IIIIIIIIII 代表DBID。DBID 以十进制输出，因此可以方便地将它与目标数据库关联起来。
YYYYMMDD 是生成备份当天的公历时间戳。
QQ 是序列号（十六进制数字），从00 开始，最大值为'FF' (256)。
示例：
RMAN> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE disk
2> TO 'controlfile_%F';

RMAN问题与监控
可以使用以下视图获取在控制文件中存储的RMAN 信息：
V$ARCHIVED_LOG 显示在数据库中已经创建、备份或清除的归档文件。
V$BACKUP_CORRUPTION 显示在备份集的备份过程中找到的损坏块。
V$COPY_CORRUPTION 显示映像复制过程中找到的损坏块。
V$BACKUP_DATAFILE 用于通过确定各数据文件中的块数来创建大小相同的备份集。通过它也可以找出数据文件中已损坏的块数。
V$BACKUP_REDOLOG 显示在备份集中存储的归档日志。
V$BACKUP_SET 显示已经创建的备份集。
V$BACKUP_PIECE 显示为备份集创建的备份片。

监视RMAN 备份
要在备份过程中将某一进程与一个通道关联起来，请：
1. 启动恢复管理器并连接到目标数据库和恢复目录（与后者的连接是可选的）。
rman target / catalog rman/rman@rcat
2. 在分配通道后，设置COMMAND ID 参数，然后复制所需的对象。
run {
allocate channel t1 type disk;
set command id to 'rman';
copy datafile 1 to '/u01/backup/df1.cpy';
release channel t1;}
3. 查询V$SESSION_LONGOPS 视图以获得复制的状态。
SELECT sid, serial#, context, sofar, totalwork
round(sofar/totalwork*100,2) "% Complete",
FROM v$session_longops
WHERE opname LIKE 'RMAN:%'
AND opname NOT LIKE 'RMAN: aggregate%';
4. 使用SQL*Plus 并查询V$PROCESS 和V$SESSION 以获得SID 和SPID。然后，
使用操作系统实用程序来监视进程或线程。
SELECT sid, spid, client_info
FROM v$process p, v$session s
WHERE p.addr = s.paddr
AND client_info LIKE '%id=rman%';
要监视复制进程，必须查询目标数据库，因此，目标数据库应该处于“打开” 或“装载”状态。

RMAN其他问题
恢复管理器异常终止：恢复管理器只在控制文件中记录已成功备份的备份集。如果恢复管理器作业异常终止，则操作系统中可能存在没有完成的文件。恢复管理器不使用这些文件，但您应该将它们删除。
检测损坏：恢复管理器可以检测并能够禁止执行一些操作，如导致备份文件无法使用或造成还原的数据文件损坏的操作。缺省情况下将启用对物理损坏的错误检查。
有关在备份过程中遇到的损坏数据文件块的信息将记录在控制文件和警报日志中。服务器可以识别损坏的数据文件块，但这些损坏块仍包含在备份中。
Oracle 服务器在控制文件中记录损坏块的地址和损坏类型。要从控制文件查看损坏块，请通过V$BACKUP_CORRUPTION 查看备份集或通过V$COPY_CORRUPTION 查看映像副本。
RMAN 将检测数据块和索引块是否存在逻辑损坏，并将所有错误记录在alert.log 和服务器会话的跟踪文件中。缺省情况下，禁用逻辑损坏的错误检查。
检测破碎块：RMAN 读取整个数据库的块，并通过比较每个块的块头和块尾来确定块是否破碎。
如果检测到一个破碎块，则它重新读取该块，直到获取一致块为止。这就是为什么在使用RMAN进行表空间或数据文件备份时不必将表空间置于联机备份模式的原因之一。
这种机制还减少了在备份过程中生成的重做日志的数量，因为这样就不必将整个块都写入重做日志文件了。

RMAN恢复
和手动管理的恢复一样，RMAN的恢复有完全恢复和不完全恢复，本节内容主要是如何使用RMAN完成完全恢复和不完全恢复。
RMAN的恢复操作比手动的恢复要简单的多，这是因为RMAN在备份期间自动记录了很多备份信息。

RMAN 在还原和恢复操作中的用法
使用RMAN 执行还原和数据文件介质恢复，RMAN 自动执行还原文件的过程。发出RESTORE 命令后，RMAN 将使用服务器会话还原正确的备份和副本。
RMAN 资料档案库用于选择最完整的可用备份集或映像副本来进行还原。缺省情况下，如果某一文件已处于正确位置且其文件头包含有正确的信息，则RMAN 将不还原该文件。
而在Oracle9i 以前的版本中，将始终还原该文件。发出RMAN RECOVER 命令后，RMAN 将应用联机重做日志文件和归档重做日志文件中的更改，或使用增量备份来恢复已还原的文件。
使用RMAN 可以在以下级别执行恢复数据库，表空间，数据文件。在完全恢复过程中，归档重做日志文件和联机重做日志文件中的所有重做条目都将用于恢复数据库。
损坏的文件将从备份进行还原，而日志文件则用于将数据文件更新到当前时间点。

ARCHIVELOG 模式下执行完全恢复
使用RMAN 还原ARCHIVELOG 模式下的数据库。在该示例中，使用RMAN 来还原并恢复整个数据库。该示例假定：磁盘上有使用RMAN 生成的完全备份。当前控制文件未损坏，无需还原。所有数据文件都已损坏或丢失。
rman target /
RMAN> STARTUP MOUNT
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

将数据文件还原到其它位置
如果遇到介质故障，如磁盘驱动器丢失，则可能需要将数据文件还原到新位置。可以如下面这么操作：
1. 连接到RMAN。
rman target
2. 装载数据库。
RMAN> STARTUP MOUNT
3. 使用RMAN 将数据文件还原到新位置并在控制文件中记录更改。
run{
set newname for datafile 1 to ‘/<newdir>/system01.dbf’;
restore database;
switch datafile all;
recover database;
alter database open; }

使用RMAN恢复表空间和重新定位表空间
使用RMAN 恢复表空间，如果已确定需要还原和恢复USERS 表空间，则可发出下面的RMAN 命令：
run{
sql “alter tablespace users offline immediate”;
restore tablespace users;
recover tablespace users;
sql “alter tablespace users online”;使用RMAN恢复表空间和重新定位表空间
使用RMAN 恢复表空间，如果已确定需要还原和恢复USERS 表空间，则可发出下面的RMAN 命令：
run{
sql “alter tablespace users offline immediate”;
restore tablespace users;
recover tablespace users;
sql “alter tablespace users online”;}

使用RMAN 重新定位表空间，如果由于磁盘故障而无法访问某一数据文件，则需要将其还原到一个新位置或切换到现有的映像副本。
如果由于某个驱动器的磁盘空间不足，或需要重新组织数据库来提高性能，因而您需要重新定位表空间，上述过程也非常有用。下面看一个例子：
当前，u03 已经损坏，但数据库仍然打开。有时用户会抱怨无法访问编号为3 的数据文件中的信息。按照以下过程操作可将该数据文件还原到一个新位置：
1. 使用以下命令检查u03 上数据文件的位置和大小：
SQL> SELECT file#, name, bytes FROM v$datafile;
FILE# NAME BYTES
----- ------------------------ ----------
1 /ORADATA/u01/system01.dbf 120586240
2 /ORADATA/u02/undotbs.dbf 31457280
3 /ORADATA/u03/users01.dbf 5242880
...
确定u04 上是否有足够的空间来容纳数据文件3。
2. 确保文件（如果需要，则为表空间）处于脱机状态，以便可以使用RESTORE 命令成
功还原。
3. 因为文件已复制到一个新位置（使用SET NEWNAME 命令），所以必须使用SWITCH
命令通知Oracle 服务器新的文件位置，以使该文件成为当前文件。
4. 使用RECOVER 命令开始将增量备份、累积备份、归档重做日志文件和联机重做日志
的组合应用于已还原的文件，以便使数据库同步。
5. 完成恢复后，使数据文件联机。通知用户数据库可以使用，需要重新输入系统发生故
障前未提交的所有数据。
可以使用以下命令：
RUN{
SQL “alter tablespace users offline immediate”;
SET NEWNAME FOR datafile ‘/ORADATA/u03/users01.dbf’
to ‘/ORADATA/u04/users01.dbf’; #Specify where to restore the file
RESTORE (tablespace users); #Restore the datafile
SWITCH datafile 3;#Update the control file and recovery catalog
RECOVER TABLESPACE users; #Recover the tablespace
SQL “alter tablespace tbs1 online”;}

RMAN不完全恢复
使用RMAN进行不完全恢复的过程，与手动的不完全恢复基本是一样的，只是不用再手动的查找备份文件在哪里，只需一条restore命令，RMAN会自动的根据记录的备份信息，查找应该到哪里寻找恢复用的备份片。

使用RMAN进行不完全恢复的过程
1. 装载数据库。
2. 为并行化分配多个通道。
3. 还原所有数据文件。
4. 使用UNTIL TIME、UNTIL SEQUENCE 或UNTIL SCN恢复数据库。
5. 使用RESETLOGS 打开数据库。
6. 执行整体数据库备份。
不完全恢复的还原和恢复进程的步骤和语法与完全恢复相同，只是需要从过去的备份中还原所有数据文件。
目标数据库必须处于已装载的状态。要还原的文件必须处于脱机状态。只有在备份是通过RMAN 生成或注册的情况下，才能使用RMAN 进行还原。

使用UNTIL TIME 进行不完全数据库恢复
使用UNTIL TIME 进行RMAN 不完全恢复的示例，在2000 年12 月9 日星期二夜间12 点，确定EMPLOYEES 表被删除后，立即关闭数据库并开始恢复。
已知故障发生的大概时间，并且上午11 点44 分以来没有更改过数据库结构。在此情况下，可以使用UNTIL TIME 方法：
1. 如果目标数据库已打开，则彻底关闭它。
2. 装载目标数据库。不要在恢复期间备份数据库。
3. 确保NLS_LANG 和NLS_DATE_FORMAT 环境变量已正确设置：
$NLS_LANG=american
$NLS_DATE_FORMAT=’YYYY-MM-DD:HH24:MI:SS’
4. 启动恢复管理器并连接至目标数据库。
$rman target rman/rman@DB00
5. 可分配多个通道以改善性能：
RMAN> run {allocate channel c1 type DISK;
allocate channel c2 type DISK;
6. 指定使用RMAN 命令从备份恢复和还原所有数据文件的时间。RMAN 根据SET
UNTIL 命令选择正确的文件：
RMAN> ... set until time = ‘2000-12-09:11:44:00’;
RMAN> ... restore database;
注：如果需要将归档重做日志文件还原到新位置，则可使用RMAN SET
ARCHIVELOG DESTINATION TO <location> 命令。
7. 将数据库恢复到SET UNTIL 命令中指定的时间：
RMAN> ... recover database;
8. 使用RESETLOGS 选项打开数据库：
RMAN> ... alter database open resetlogs; }
9. 确认表存在，然后执行备份。
10. 通知用户数据库可以使用，需要重新输入系统发生故障前未提交的所有数据。
11. 如果使用恢复目录，则注册数据库的新复本：

使用UNTIL SEQUENCE 进行不完全数据库恢复
使用UNTIL SEQUENCE 进行RMAN 不完全恢复的示例，UNTIL SEQUENCE 子句指定重做日志序列号和线程号的上限。
RMAN 对日志序列号小于指定日志序列号的文件执行操作。以上示例假定日志序列号120 由于磁盘损坏而丢失，需要使用可用的归档重做日志恢复数据库。
RMAN> RUN {
2> SET UNTIL SEQUENCE 120 THREAD 1;
3> ALTER DATABASE MOUNT;
4> RESTORE DATABASE;
5> RECOVER DATABASE; # recovers through log 119
6> ALTER DATABASE OPEN RESESTLOGS;
7> }

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
备份恢复示例
非归档模式下的备份与恢复
非归档模式下的备份以冷备为主，可以适当采用RMAN的增量备份恢复。总的来说，除非有其他方法可以保证数据的安全，或者数据的安全性并不是非常重要，不要使用非归档模式。
备份方案：采用OS冷备份
1.连接数据库并创建测试表
SQL*Plus: Release 10.2.0.3.0 - Production on Tue May 6 13:46:32 2003
(c) Copyright 1999 Oracle Corporation. All rights reserved.
SQL> connect internal/password as sysdba;
Connected.
SQL> create table test(a int);
Table created
SQL> insert into test values(1);
1 row inserted
SQL> commit;
Commit complete
2.备份数据库
SQL> @coldbak.sql 或在DOS下svrmgrl @coldbak.sql
3.再插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from test;
4.关闭数据库
SQL> shutdown immediate;
5.毁坏一个或多个数据文件，如删除user01.dbf
C:\>del D:\ORACLE\ORADATA\TEST\USERS01.DBF
6.重新启动数据库，会发现错误
SQL> startup
在报警文件中，会有更详细的信息
7.拷贝备份复原到原来位置(restore过程)
C:\>xcopy d:\database\*.* d:\oracle\oradata\test/H/R/S
8.打开数据库，检查数据
SQL> alter database open;
Database altered.
SQL> select * from test;
这里可以发现，数据库恢复成功，但在备份之后与崩溃之前的数据丢失了。
说明：
1、非归档模式下的恢复方案可选性很小，一般情况下只能有一种恢复方式，就是数据库的冷备份的完全恢复，仅仅需要拷贝原来的备份就可以(restore)，不需要recover。
2、这种情况下的恢复，可以完全恢复到备份的点上，但是可能是丢失数据的，在备份之后与崩溃之前的数据将全部丢失。
3、不管毁坏了多少数据文件或是联机日志或是控制文件，都可以通过这个办法恢复，因为这个恢复过程是Restore所有的冷备份文件，
而这个备份点上的所有文件是一致的，与最新的数据库没有关系，就好比把数据库又放到了一个以前的“点”上。
4、对于非归档模式下，最好的办法就是采用OS的冷备份，建议不要用RMAN来作冷备份，效果不好，因为RMAN不备份联机日志，restore不能根本解决问题。
5、如果没有备份联机日志，如RMAN的备份，就需要利用不完全恢复(until cancel)的方法来重新创建联机日志文件。

归档模式下丢失或损坏数据文件
OS备份方案
在归档方式下损坏或丢失一个数据文件，如果存在相应的备份与该备份以来的归档日志，恢复还是比较简单的，可以作到尽量少的Down机时间，并能作到数据库的完全恢复。
1、连接数据库，创建测试表并插入记录
SQL> create table test(a int) tablespace users;
SQL> insert into test values(1);
SQL> commit;
2、备份数据库
SQL> @hotbak.sql 或在DOS下svrmgrl @hotbak.sql
3、继续在测试表中插入记录
SQL> insert into test values(2);
SQL> commit;
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
4、关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
5、启动数据库错误，脱机该数据文件
SQL> startup
还可以查看报警文件（见上一个恢复案例）或动态视图v$recover_file
如SQL> select * from v$recover_file;
脱机数据文件
SQL> alter database datafile 3 offline drop;
6、打开数据库，拷贝备份回来(restore)，恢复(recover)该数据文件，并联机
SQL> alter database open;
拷贝备份从备份处
copy d:\databak\ users01.dbf d:\oracle\oradata\test;
恢复该数据文件
SQL> recover datafile 3;
Log applied.
Media recovery complete.
恢复成功，联机该数据文件
SQL> alter database datafile 3 online;
7、检查数据库的数据（完全恢复）
SQL> select * from test;
说明：
1、采用热备份，需要运行在归档模式下，可以实现数据库的完全恢复，也就是说，从备份后到数据库崩溃时的数据都不会丢失。
2、可以采用全备份数据库的方式备份，对于特殊情况，也可以只备份特定的数据文件，如只备份用户表空间（一般情况下对于某些写特别频繁的数据文件，可以单独加大备份频率）
3、如果在恢复过程中，发现损坏的是多个数据文件，即可以采用一个一个数据文件的恢复方法（第5步中需要对数据文件一一脱机，第6步中需要对数据文件分别恢复），也可以采用整个数据库的恢复方法。
4、如果是系统表空间的损坏，不能采用此方法

RMAN备份方案
RMAN也可以进行联机备份，而且备份与恢复方法将比OS备份更简单可靠。
1、连接数据库，创建测试表并插入记录
SQL> create table test(a int) tablespace users;
SQL> insert into test values(1);
SQL> commit;
2、备份数据库表空间users
RMAN> run{
2> allocate channel c1 type disk;
3> backup tag 'tsuser' format 'd:\backup\tsuser_%u_%s_%p'
4> tablespace users;
5> release channel c1;
6> }
3、继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
SQL> alter system switch logfile;
4、关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
5、启动数据库，检查错误
SQL> startup
6、先打开数据库
SQL> alter database datafile 3 offline drop;
SQL> alter database open;
7、恢复该表空间
恢复脚本可以是恢复单个数据文件
run{
allocate channel c1 type disk;
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
release channel c1;
}
也可以是,恢复表空间
run{
allocate channel c1 type disk;
restore tablespace users;
recover tablespace users;
sql 'alter database datafile 3 online';
release channel c1;
}
8、检查数据是否完整
SQL> alter database open;
SQL> select * from test;
说明：
1、RMAN也可以实现单个表空间或数据文件的恢复，恢复过程可以在mount下或open方式下，如果在open方式下恢复，可以减少down机时间。
2、如果损坏的是一个数据文件，建议offline并在open方式下恢复。
3、这里可以看到，RMAN进行数据文件与表空间恢复的时候，代码都比较简单，而且能保证备份与恢复的可靠性，所以建议采用RMAN的备份与恢复。

丢失多个数据文件，实现整个数据库的恢复
OS备份方案
OS备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复
1、连接数据库，创建测试表并插入记录
SQL> create table test(a int) tablespace users;
SQL> insert into test values(1);
SQL> commit;
2、备份数据库，备份除临时数据文件后的所数据文件
SQL> @hotbak.sql 或在DOS下svrmgrl @hotbak.sql
3、继续在测试表中插入记录
SQL> insert into test values(2);
SQL> commit;
SQL> alter system switch logfile;
4、关闭数据库，模拟丢失数据文件
SQL> shutdown immediate;
5、启动数据库，检查错误
SQL> STARTUP
详细信息可以查看报警文件
通过查询v$recover_file可以看到
6、拷贝备份回到原地点(restore)，开始恢复数据库(recover)
Recover过程:
SQL> recover database;
7、打开数据库，检查数据库的数据（完全恢复）
SQL> alter database open;
Database altered.
SQL> select * from test;
说明：
1、只要有备份与归档存在，就可以实现数据库的完全恢复（不丢失数据）
2、适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复
3、恢复过程在mount下进行，如果恢复成功，再打开数据库，down机时间可能比较长一些。

RMAN备份方案
RMAN备份归档模式下损坏（丢失）多个数据文件，进行整个数据库的恢复
1、连接数据库，创建测试表并插入记录
SQL> create table test(a int) tablespace users;
SQL> insert into test values(1);
SQL> commit;
2、备份数据库
11> run{
12> allocate channel c1 type disk;
13> backup full tag 'dbfull' format 'd:\backup\full%u_%s_%p' database
14> include current controlfile;
15> sql 'alter system archive log current';
16> release channel c1;
17> }
3、继续在测试表中插入记录
SQL> insert into test values(2);
1 row inserted
SQL> commit;
SQL> alter system switch logfile;
SQL> alter system switch logfile;
4、关闭数据库，模拟丢失数据文件
5、启动数据库，检查错误
6、利用RMAN进行恢复
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database;
5> sql 'alter database open';
6> release channel c1;
7> }
7、检查数据库的数据（完全恢复）
SQL> select * from test;
说明：
1、只要有备份与归档存在，RMAN也可以实现数据库的完全恢复（不丢失数据）
2、同OS备份数据库恢复，适合于丢失大量数据文件，或包含系统数据文件在内的数据库的恢复
3、目标数据库在mount下进行，如果恢复成功，再打开数据库。
4、RMAN的备份与恢复命令相对比较简单并可靠，建议有条件的话，都采用RMAN进行数据库的备份。

不完全恢复案例
不完全恢复，是应对误操作的重要的恢复手段。除误操作外，对于有些情况的介质损坏，也必须使用不完全恢复才能解决，比如当前联机重做日志损坏。
不完全恢复将会丢失部分数据，这从它的名字“不完全”上，也可以看的出来。

OS备份下的基于时间的恢复
不完全恢复可以分为基于时间的恢复，基于改变的恢复与基于撤消的恢复，这里已基于时间的恢复为例子来说明不完全恢复过程。
基于时间的恢复可以不完全恢复到现在时间之前的某一个时间，对于某些误操作，如删除了一个数据表，可以在备用恢复环境上恢复到表的删除时间之前，然后把该表导出到正式环境，避免一个人为的错误。
1、连接数据库，创建测试表并插入记录
2、备份数据库，这里最好备份所有的数据文件，包括临时数据文件
3、删除测试表，假定删除前的时间为T1，在删除之前，便于测试，继续插入数据并应用到归档。
4、准备恢复到时间点T1，找回删除的表，先关闭数据库
SQL> shutdown immediate;
5、拷贝刚才备份的所有数据文件回来
6、启动到mount下
7、开始不完全恢复数据库到T1时间
SQL> recover database until time '2003-05-21:14:43:01';
8、打开数据库，检查数据
SQL> alter database open resetlogs;
说明：
1、不完全恢复最好备份所有的数据，冷备份亦可，因为恢复过程是从备份点往后恢复的，如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点，那么恢复都是不可能成功的。
2、不完全恢复有三种方式，过程都一样，仅仅是recover命令有所不一样，这里用基于时间的恢复作为示例。
3、不完全恢复之后，都必须用resetlogs的方式打开数据库，建议马上再做一次全备份，因为resetlogs之后再用以前的备份恢复是很难了。
4、以上是在删除之前获得时间，但是实际应用中，很难知道删除之前的实际时间，但可以采用大致时间即可，或可以采用分析日志文件(logmnr)，取得精确的需要恢复的时间。
5、一般都是在测试机后备用机器上采用这种不完全恢复，恢复之后导出/导入被误删的表回生产系统

RMAN备份下的基于改变的恢复
以上用OS备份说明了一个基于时间的恢复，现在用RMAN说明一个基于改变的恢复
1、连接数据库，创建测试表并插入记录
2、备份数据库
RMAN> run{
2> allocate channel c1 type disk;
3> backup full tag 'dbfull' format 'd:\backup\full%u_%s_%p' database
4> include current controlfile;
5> sql 'alter system archive log current';
6> release channel c1;
7> }
3、删除测试表，在删除之前，便于测试，继续插入数据并应用到归档，并获取删除前的scn号。
SQL> alter system switch logfile;
SQL> alter system switch logfile;
SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) scn from x$ktuxe;
4、准备恢复到SCN 31014，先关闭数据库，然后启动到mount下
5、开始恢复到改变点SCN 31014
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database until scn 31014;
5> sql 'ALTER DATABASE OPEN RESETLOGS';
6> release channel c1;
7> }
6、检查数据
说明：
1、RMAN也可以实现不完全恢复，方法比OS备份恢复的方法更简单可靠
2、RMAN可以基于时间，基于改变与基于日志序列的不完全恢复，基于日志序列的恢复可以指定恢复到哪个日志序列，如
run {
allocate channel ch1 type disk;
allocate channel ch2 type 'sbt_tape';
set until logseq 1234 thread 1;
restore controlfile to '$ORACLE_HOME/dbs/cf1.f' ;
replicate controlfile from '$ORACLE_HOME/dbs/cf1.f';
alter database mount;
restore database;
recover database;
sql "ALTER DATABASE OPEN RESETLOGS";
}
3、与所有的不完全恢复一样，必须在mount下，restore所有备份数据文件，需要resetlogs
4、基于改变的恢复比基于时间的恢复更可靠，但是可能也更复杂，需要知道需要恢复到哪一个改变号(SCN)，在正常生产中，获取SCN的办法其实也有很多，
如查询数据库字典表(V$archived_log or v$log_history)，或分析归档与联机日志(logmnr)等。