--================================
-- Oracle 基于用户管理恢复的处理
--================================
Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整。除了使用RMAN工具以及第三方备份与恢复工具之外，基于
用户管理的备份与恢复也是DBA经常使用的方式之一。本文首先介绍了恢复的相关概念，接下来详细讲述了在归档模式下使用基于用户管理恢
复的处理过程。
一、恢复的相关概念
介质恢复
首先使用备份还原数据，然后再应用归档日志、重做日志的恢复方式称为介质恢复。
介质恢复能将一个经过还原的数据更新到当前的时间点或之前的某个时间点。
通常介质恢复这个术语专指对数据文件进行恢复的过程。
数据块的介质恢复指数据文件中的个别数据块出现错误时进行的特殊恢复操作。
介质恢复通常又可以分为完全恢复和不完全恢复
完全恢复
使用数据库,表空间或数据文件的备份进行还原,再使用归档,重做日志或增量备份将数据更新到当前时间点
用户可以实现基于对数据库、表空间、数据文件执行完全恢复
对整个数据库实现完全恢复的步骤
启动数据库到mount 状态
确保所有需要被恢复的数据文件处于联机（online）状态
还原数据库或需要恢复的数据文件
应用联机重做日志或/与归档重做日志
对表空间及数据文件实现完全恢复的步骤
如果数据库处于打开状态，应将需要恢复的表空间或数据文件置为脱机(offline)状态
还原需要恢复的数据文件
应用联机重做日志或/与归档重做日志
使表空间或数据文件联机
不完全恢复
与完全恢复是同样的步骤，只不过不完全恢复仅仅是将数据恢复到某一个特定的时间点或特定的SCN，而
不是当前时间点。下列情况通常需要进行不完全恢复：
介质故障(media failure)导致部分或全部联机重做日志(online redo log)损坏
用户操作失误(user error)导致数据丢失,例如,用户由于疏忽而移除了表,提交了无效的数据到表
由于归档重做日志(archived redo log)丢失而无法进行完全恢复(complete recovery)
当前控制文件(control file)丢失，必须使用备份的控制文件打开(open)数据库
不完全恢复的步骤
关闭数据库并备份数据库(以防止恢复失败)
启动数据库到mount 状态
还原所有受损的数据文件，同时可以选择还原控制文件
将数据库恢复至某个时间点、序列、或系统改变号
使用RESETLOGS关键字打开数据库
注意：
在做不完全恢复前建议在恢复前后做一次备份，避免恢复失败导致不必要的损失
不完全恢复完成后，建议不要直接使用OPEN RESETLOGS 命令以读/写模式打开(open)数据库，而应先以只读模式打开数据库，
并检查是否已将数据库恢复到正确的时间点。如果恢复的时间点有误，在没有使用OPEN RESETLOGS命令的情况下，重新执
行恢复操作相对简单。如果恢复结果早于指定的时间点，只需重新执行恢复操作。如果恢复结果超过了指定的时间点，则
应再次还原数据库并重新进行恢复。
Flashback Database(闪回数据库)是一种进行不完全恢复的方法
不完全介质恢复的几种类型：
基于时间的恢复(Time-based recovery) 将数据恢复到指定的时间点
用户控制的恢复(Cancel-based recovery) 当用户提交CANCEL后停止恢复(此选项在使用RMAN时无效)
基于SCN 的恢复(Change-based recovery) 将数据恢复到指定的SCN
按重做日志序号恢复(Log sequence recovery)将数据恢复到指定的重做日志序号(仅使用RMAN时有效)
表空间按时间点恢复(tablespace point-in-time recovery，TSPITR)
可以将一个或多个表空间恢复到与数据库中其他表空间不同的时间点
TSPITR的适用情况：
因错误地移除(drop)及清除(truncate)表而进行的恢复
恢复存在逻辑错误的表
由于不正确的批处理作业或其他DML 语句导致数据库中部分数据有误，因而需要恢复
单独将某个方案(schema)恢复到与物理数据库中其他方案不同的时间点
(假设数据库中不同的方案使用不同的表空间)
恢复大型数据库(VLDB)中的一个表空间，而不必先使用备份复原整个数据库再执行所有前滚(roll-forward)操作
TSPITR的限制
SYSTEM表空间,UNDO表空间,或任何包含回滚段(rollback segment)的表空间无法使用TSPITR功能
与其它表空间有依赖性的表空间应当同时恢复被依赖的表空间，如两张表存在依赖性且位于不同的表空间
数据文件的介质恢复
用于对丢失或损坏的数据文件及控制文件进行恢复
也可恢复因没有使用OFFLINE NORMAL 选项执行脱机操作而造成数据丢失的表空间
数据文件介质恢复具有以下特点：
能够将数据修改应用到被还原(restore)的受损数据文件中。
能够使用归档重做日志(archived redo log)及联机重做日志(online redo log)。
需要用户显式的执行。
不能自动地检测介质故障(media failure)(即不能自动地执行复原操作)。但在使用备份进行复原后，能够自动地检测是否需要
通过介质恢复(media recovery)来恢复数据。
恢复所需时间完全由用户备份恢复策略(例如备份频率,并行恢复参数,上次备份后数据库内的事务量)决定,与Oracle内部机制无关
如果数据库内存在需要介质恢复(media recovery)的联机数据文件(online datafile)，那么此数据库将无法打开(open)，如果一个
数据文件需要介质恢复，那么此文件将无法联机。因此需要脱机该数据文件(非系统数据文件)再打开数据库。
在出现以下情况时需要进行介质恢复：
使用备份还原了一个数据文件。
使用备份还原了一个控制文件（即使此时所有数据文件都是最新的）。
将数据文件脱机(offline)时(无论是用户手动执行的，还是Oracle 自动执行的)没有使用OFFLINE NORMAL 选项。
如果数据库已经被一个实例打开，数据文件介质恢复将只能针对脱机数据文件。即便数据库只需进行崩溃恢复(crash recovery)，
用户也可以在数据库打开前执行介质恢复。此时，崩溃恢复仍会在数据库打开时自动运行。
需要注意的是，如果一个文件需要介质恢复，即使所有对此文件的修改都包含在联机重做日志文件中也必须进行介质恢复.也就是说，
即使无需应用归档重做日志也必须进行介质恢复。如果对无需恢复的数据文件执行了介质恢复，那么介质恢复将发现自己无需进行
任何处理，并发出"no recovery required(无需恢复)"错误。
数据块介质恢复（block media recovery）
能够在所有数据文件联机且可用的情况下对个别的数据块进行还原(restore)及恢复(recover)。如果数据错误局限在某些数据文件的
少量数据块中，此时适宜采用数据块介质恢复来对数据文件进行恢复。
数据块介质恢复是通过RMAN 来执行的。如果用户没有使用RMAN 作为数据库的备份方案，可以向RMAN存储仓库(repository)中添
加相关的用户管理的数据文件(user-managed datafile)信息及归档重做日志备份(archived redo log backup)信息，这样也能使用
RMAN 进行数据块介质恢复。