.　如果不能接受丢失数据库的修改，那么必须重新创建表空间
　　在这种情形下，你可以使用全数据库导出或者冷热备份结合的方式来重构数据库。要注意的是无论你选择哪种方式，在线redo log中的事务都会丢失。

[NextPage] 事件4：恢复一个特别的表
　　在知道哪些用户在"pending offline"的回滚段上有活动的事务后，可以要求他们提交或者回滚他们的事务，或者可以使用以下的命令杀掉它们的进程：
　　　3、使用最新的全数据库导出来导入，并且使用ignore=y的选项；
　　　4、如果是硬件的问题，复制一个好的控制文件拷贝到一个可靠的位置

　　如果只是丢失了其中的一个控制文件，可以采用下面的步骤来恢复：

　　可以采用以下的步骤恢复：
　　　每个星期都进行冷备份
　　事件1：完整的数据库重构
　　　每日都进行一次全数据库导出
　　　6、启动数据库

　　在这种事件下，将丢失全部活动的事务，并且需要重新创建回滚段。这样大的问题可能是由于一个硬件问题造成的，可以采用以下的步骤恢复：
　　　8、对数据库进行一次冷备份
　　事件3：丢失一般的数据文件
　　　4、使用CREATE CONTROLFILE重新创建控制文件、你也可以备份控制文件到一个trace文件，然后执行该文件
　　　6、在你处理完所有活动的事务后，执行以下的步骤：

　　　3、startup mount数据库



　　　1、不要关闭数据库、对于这种事件，数据库启动比关闭更容易解决问题、

　　事件6：丢失全部的控制文件
　
　　要注意的是活动的事务将会丢失
　　　5、编辑initsid.ora 或者 configsid.ora，更新CONTROL_FILES以反映最新的控制文件位置

　　　控制文件是镜像的


　　　3、离线删除涉及的数据文件


　　如果上面的查询没有结果，那么所有的回滚段都是离线的，但是，如果上面的查询返回一行或者多行，并且其状态为PENDING OFFLINE，那么可检查这些回滚段的ACTIVE_TX列、带有0值的回滚段将很快会离线；但是，非0的值表示上面有活动的事务，它们需要被提交或者回滚、

　　　2、startup mount数据库
　　事件7：丢失一个索引


　　事件8：丢失一个非活动的redo log







　　　3、删除全部离线的回滚段





　　以下的步骤可以用作恢复：


　　　7、使用shutdown normal关闭数据库
　　　2、查找丢失控制文件的原因、是由于硬件的问题吗（磁盘还是控制器）？
　　最简单的方法就是重新创建丢失的索引



　　这里指的是丢失一个回滚段的一个数据文件、这是一个危急的恢复过程，它主要是在于保存活动的事务。这里假定数据库已经起来，而你想保存当前运行的事务。要使用以下的恢复过程，数据库必须运行在archivelog模式下。

　　　4、离线删除涉及的数据文件

　　　6、打开数据库
　　　3、Startup mount数据库

　　　7、通过全数据库备份重新创建表空间和其中的对象

　　　数据库运行在archivelog模式


　　　　重新创建回滚表空间
　　　2、令属于该数据文件中的全部回滚段离线
　　7、打开数据库



　　6、通过使用存档和在线的redo log来恢复数据文件

　　　2、关闭数据库
　　　5、打开数据库
　　可以使用以下步骤恢复：

　　　2、重新创建表空间
　　事件5：丢失控制文件
　　　1、如果它正在运行的话，先关闭它
　　　4、打开数据库
　　　4.关闭并且重新以normal的模式启动数据库实例

　这里会讨论令Oracle停机时间最小化的步骤。各种形式的停机--计划的或者是非计划的--总是不断地发生，一个DBA应该有正确的备份策略，这样在数据库出现问题时就可以更快地恢复。 
　　　1、关闭数据库

　　　ALTER SYSTEM KILL SESSION 'sid, serial#';

[NextPage] 事件12：丢失全部的回滚段
　　　6、删除用户的表空间，包括其中的内容、



　　事件10：丢失存档的Redo log文件