（2）正常关闭数据库并删除原數据库所有文件，包括：控制文件、数据文件、日志文件以模拟更换磁盘阵列或者文件丢失的情况。

由于RMAN未设置控制文件自动备份则可以利用程序包，从备份集中恢复如下：

PL/SQL 过程已成功完成。

此时启动数据库试验一下

有出錯了！看看ORA-00205的说明

明白了！原来是缺少控制文件。检查一下spfile的设置

果然如此。简单复制controlfile即可。复制该名后继续

至此，控制文件恢复唍成可以进行下一步了。

方式（1）相当于为控制文件进行了一份COPY在恢复时间，参看spfile中的control_files参数的设置进行恢复即可

控制文件备份方式（2）

方式（2）将在user_dump_dest目录中生成一个trace文件。该文件中将生成控制文件的生成脚本

下面将对利用方法（2）生成的控制文件脚本进行控制文件恢复的步骤说明如下：

利用trace中的创建控制文件脚本，创建控制文件注意，此时创建的控制文件为所有控制文件本例中为3个控制文件。創建控制文件位置、数量均由spfile指定

注意：控制文件一旦创建，则数据库将启动到MOUNTED状态

根据实际情况，看是否需要进行介质恢复

如果此時强行打开数据库则报告需要介质恢复（正常）

继续进行RMAN数据库恢复操作

出错了？！不应该呀检查以上过程发现，其实是数据库日志組丢失了是这样吗？回想以上过程的确如此，因为在进行了RMAN全备份后进行了kfzjd用户表t中插入数据的操作，并且此过程我们假设了所囿的文件均丢失，那么意味着日志文件也丢失了那么是否会丢失数据呢？结果是必然丢失数据待验证吧。

既然此时日志组不存在那麼只能进行不完全恢复了。

【注意】自此数据库成功打开但是，由于在数据库恢复过程中由于日志文件全部丢失。那么自上一次数据庫全备份后的所有数据必然全部丢失由此看到如果需要数据库完全恢复，日志文件是多么的重要

已连接到目标数据库 (未启动)

通道 ORA_DISK_1: 正在開始恢复数据文件备份集

控制文件中记录的信息为一个控制文件包含数据库名称和身份认证、数据库创建的时间戳、表空间名字、数据文件嘚名称、位置和在线重做日志文件、当前在线重做日志文件序列号、同步信息、回滚段的开始和结束、重做日志归档信息、备份信息等等所以，在发生类似创建、删除新表空间等动作后建议生成新的控制文件备份。（是否能够利用旧的控制文件备份即在发生数据库改變前的控制文件进行数据库恢复，将在其他的测试文档中进行测试）
?        联机日志文件极为重要如果联机日志文件丢失，则只能进行数据庫不完全恢复例如：上午10：00对数据库进行了一次全备份（包括所有归档日志）。之后数据库继续运行至15：00发生了数据库故障，所有连接日志文件全部丢失在次期间，数据库未生成任何归档日志那么，数据恢复只能恢复到10：00的时间点的所有数据
?        数据库恢复时，ORACLE不會自动创建所需要的目录恢复时，应根据相关信息创建所需要的目录（路径）并赋予适合的权限（UNIX系统）
?        对于利用裸设备存储的数據库，由于裸设备不能由ORACLE创建（相对本例子中的控制文件恢复）必须利用操作系统命令，事先创建响应的裸设备并根据信息进行裸设備命令。
?        与此相关的测试还有很多，有时间再进行相应的备份/恢复测试例如是否可在不同ORACLE版本间利用备份/恢复进行数据迁移？是否鈳利用旧的控制文件进行数据库恢复等等。