这里会讨论令Oracle停机时间最小化的步骤。各种形式的停机--计划的或者是非计划的--总是不断地发生，一个DBA应该有正确的备份策略，这样在数据库出现问题时就可以更快地恢复。
以下是假定的备份策略和数据库的运作条件
控制文件是镜像的
数据库运行在archivelog模式
每个星期都进行冷备份
每日都进行热备份
每日都进行一次全数据库导出
事件1：完整的数据库重构
在这种情形下，你可以使用全数据库导出或者冷热备份结合的方式来重构数据库。要注意的是无论你选择哪种方式，在线redolog中的事务都会丢失。
事件2：恢复部分的表空间
可以使用以下的步骤来恢复：
1、以restrict模式启动数据库
2、重新创建表空间
3、使用最新的全数据库导出来导入，并且使用ignore=y的选项;
4.关闭并且重新以normal的模式启动数据库实例
事件3：丢失一般的数据文件
丢失一般数据文件的恢复步骤根据所丢失的数据文件包含的表空间类型而定;例如：回滚段，用户表空间，索引表空间或者是只读的表空间、你可能会遇到以下的错误：
.尝试启动数据库并且碰到错误的信息ORA-1157,ORA-1110，可能还有一个操作系统的错误
.尝试以normal或者immediate的模式关闭数据库，可能会碰到ORA-1116,ORA-1110的错误信息，还有一个系统错误
以下的步骤可以用作恢复：
1、关闭数据库
2、由热备份中恢复丢失的数据文件
3、Startupmount数据库
4、执行以下的查询来得到所有你的在线redolog文件和它们相应的次序和首次修改号：
5、如果得到的CHANGE#比在线redolog最小的FIRST_CHANGE#还小，那么该文件不能被完全恢复，你可以有两个选择：
. 如果可以接受丢失最近一次冷备份以来的数据库修改，装入备份并且继续恢复
. 如果不能接受丢失数据库的修改，那么必须重新创建表空间
6、通过使用存档和在线的redolog来恢复数据文件
7、打开数据库
事件4：恢复一个特别的表
可以采用以下的步骤恢复：
1、使用最近的一次全数据库导出来导入表，并且使用owner=和tables=的选项
2、考虑到性能的原因，可能需要重建表索引
事件5：丢失控制文件
在数据库起来并且运行时，通常都不能检测到控制文件的问题、如果控制文件丢失或者损坏了，Oracle将不会了解，下次数据库的启动时将会导致ORA-205错误(标识控制文件"%s的错误)，还有一个系统级的错误、
如果只是丢失了其中的一个控制文件，可以采用下面的步骤来恢复：
1、如果它正在运行的话，先关闭它
2、查找丢失控制文件的原因、是由于硬件的问题吗(磁盘还是控制器)?
3、如果不是硬件的问题，将控制文件的一个好的拷贝复制到丢失的位置，并且跳到步骤5、
4、如果是硬件的问题，复制一个好的控制文件拷贝到一个可靠的位置
5、编辑initsid.ora或者configsid.ora，更新CONTROL_FILES以反映最新的控制文件位置
6、启动数据库
事件6：丢失全部的控制文件
可以采用以下的步骤恢复：
1、关闭数据库
2、进行一次全数据库备份，包括全部的数据文件和redolog文件
3、以NOMOUNT的状态启动数据库
4、使用CREATECONTROLFILE重新创建控制文件、你也可以备份控制文件到一个trace文件，然后执行该文件
5、在数据库上进行媒体恢复
6、打开数据库
7、使用shutdownnormal关闭数据库
8、对数据库进行一次冷备份
事件7：丢失一个索引
最简单的方法就是重新创建丢失的索引
事件8：丢失一个非活动的redolog
如果丢失redo数据，恢复将是不完全的，必须重新创建涉及的表空间。要重新创建表空间，可以使用全的数据库导出，这样就可以很容易的导入数据并且重新创建该表空间的对象。可以使用以下的步骤来恢复：
1、通过Altersystem来切换redolog文件
2、关闭数据库
3、startupmount数据库
4、离线删除涉及的数据文件
5、打开数据库
6、删除用户的表空间，包括其中的内容、
7、通过全数据库备份重新创建表空间和其中的对象
事件9：丢失活动的Redolog
如事件8讨论的一样，如果丢失了redo数据，恢复将是不完全的，必须重新创建涉及的表空间、可以采用以下的步骤恢复：
1、关闭数据库
2、startupmount数据库
3、离线删除涉及的数据文件
4、打开数据库
5、删除用户的表空间，包括其中的内容、
6、通过全数据库备份重新创建表空间和其中的对象
要注意的是活动的事务将会丢失
事件10：丢失存档的Redolog文件
如果存档的redolog文件丢失，应该马上进行一次冷备份、最好也进行一次全数据库导出、没有丢失的存档redolog文件的任何恢复都将是不完全的、
事件11：丢失活动的回滚段
这里指的是丢失一个回滚段的一个数据文件、这是一个危急的恢复过程，它主要是在于保存活动的事务。这里假定数据库已经起来，而你想保存当前运行的事务。要使用以下的恢复过程，数据库必须运行在archivelog模式下。
可以使用以下步骤恢复：
1、不要关闭数据库、对于这种事件，数据库启动比关闭更容易解决问题、
2、令属于该数据文件中的全部回滚段离线
3、删除全部离线的回滚段
4、在上面的第2步中，如果回滚段中有活动的事务，你将不能令它离线、可运行以下的查询来查看哪些事物是活动的：
如果上面的查询没有结果，那么所有的回滚段都是离线的，但是，如果上面的查询返回一行或者多行，并且其状态为PENDINGOFFLINE，那么可检查这些回滚段的ACTIVE_TX列、带有0值的回滚段将很快会离线;但是，非0的值表示上面有活动的事务，它们需要被提交或者回滚、
5、处理活动的事务、执行以下的查询来查看哪些用户的事务被指派到该回滚段：
在知道哪些用户在"pendingoffline"的回滚段上有活动的事务后，可以要求他们提交或者回滚他们的事务，或者可以使用以下的命令杀掉它们的进程：
ALTERSYSTEMKILLSESSION'sid,serial#';
6、在你处理完所有活动的事务后，执行以下的步骤：
丢弃表空间及其中的全部内容
重新创建回滚表空间
重新创建回滚段，并且令它们在线
事件12：丢失全部的回滚段
在这种事件下，将丢失全部活动的事务，并且需要重新创建回滚段。这样大的问题可能是由于一个硬件问题造成的，可以采用以下的步骤恢复：
1、关闭数据库
2、使用DBVERIFY验证全部的数据文件
3、解决其它的硬件问题或者数据文件损坏
4、以startupmount的方式启动数据库实例
5、在数据库上执行媒体恢复
6、打开数据库
7、按需要创建新的回滚段
事件13：导出文件损坏
如果导出文件不能用了，那么应该冷备份数据库并且进行一个全的数据库导出、这是假定数据库自身没有问题、如果数据库也损坏了，那么应该执行以下的步骤：
1、ORA-1157错误信息通常都表示一个或者多个的数据文件损坏了。查明哪些表受到影响，它们应该是错误信息中指明的数据文件中的表格
2、跳过坏的数据块，将数据由表格中选择到临时表格中、
3、丢弃损坏的表
4、将临时表重命名为丢弃的表
5、重新建立受影响表上的全部索引
6、使用VALIDATESTRUCTURECASCADE的选项来分析全部损坏的表
要注意的是损坏块中数据将会丢失并且不能恢复
事件14：在热备份时关机
如果在热备份正在进行的时候突然关机，其中的一些表空间将可能处在备份模式、当你尝试打开数据库时，它将只能mount，并且指示某些表空间处于热备份模式、由于数据库不能打开，你将不能让表空间脱离热备份模式、你可以使用以下的步骤恢复：
1、startupmount数据库
2、查询v$backup以查看哪些数据文件处于ACTIVE状态、
3、通过使用命令ALTERDATABASEDATAFILEENDBACKUP.来将这些数据文件脱离备份模式
4、打开数据库
事件15：恢复到某个特别的时间点
以下的步骤可用来执行point-in-time恢复
1、关闭数据库实例
2、以NOMOUNT的状态启动数据库实例
3、使用UNTIL的选项来恢复数据库
4、打开数据库
5、ShutdownNORMAL
6、启动数据库实例
事件16：恢复到一个特别的事件或者活动
可以使用以下的步骤来恢复：
1、关闭数据库实例
2、以NOMOUNT状态启动数据库实例;
3、使用UNTILCANCEL来恢复数据库，提供存档的redolog文件请求直到该活动/事件为止
4、输入CANCEL来取消恢复
5、打开数据库;
6、使用NORMAL的模式来关闭数据库
7、启动数据库实例
结论
高可用性对于任何的商业都是很重要的，ORACLEDBA可以通过一些计划以确保停机时间最小化、这篇文章讨论了不同的策略可以达到这个目的。
