做好了备份之后，在故障时就需要通过备份来进行恢复。
Oracle数据库有一个重要的组成结构：重做日志（Redo Log）。重做日志用来记录数据库操作的必要信息，以便在发生故障时能够通过事务重演来恢复数据。Oracle的数据恢复就依赖于重做日志文件（Redo Log File）以及由其衍生的归档日志文件（Archived Redo Log File）。
针对不同的故障情况，Oracle可以通过不同的方式进行数据恢复，下面我们将主要介绍对于热备份的恢复。根据不同的故障情况，热备份的恢复可以分为完全恢复和不完全恢复两类。
如果在恢复时我们拥有足够的归档日志（Archived Redo Log）和在线重做日志（Online Redo Log），那么通过恢复一个全备份，应用归档日志和重做日志，最终数据库就可以实现完全恢复，恢复后的数据库不会有任何数据损失，这个恢复如图7-1所示。
图7-1 数据恢复示意
如果恢复在应用日志完成之前停止，则进行的就是一次不完全恢复。逐渐应用日志向前恢复的过程称为前滚（Roll Forward），前滚的过程实际上就是应用日志重演事务的过程（Replay transactions），完成前滚后，数据文件将包含提交和未提交的数据，然后需要应用回滚数据，将未提交的事务回滚，这个过程称为rolling back 或transaction recovery。
通常，完全恢复应用于那些由于硬件故障导致的数据库损失，在这种情况下需要最大可能的恢复数据；不完全恢复通常用于恢复用户错误，比如用户在图7-1中Time2时间点误操作Drop掉一个业务数据表，那么恢复需要执行到Time2之前停止，这样就可以找回被误删除的数据表，此时执行的就是一次不完全恢复。
在实际管理中，很多情况下进行的是不完全恢复，选择不完全恢复的可能原因很多，最常见的情况有：
· 归档日志丢失。由于某个归档日志丢失，恢复只能执行的过去的某个时间点。
· 在线日志文件损坏。在线的日志文件损坏，则恢复只能停止在损坏的日志之前。
· 用户错误操作。用户错误地drop/truncate了数据表，恢复必须在这些动作发出前停止，以完成数据恢复。
不完全恢复主要有4种类型：基于时间的恢复（Time-based Recovery）、基于放弃的恢复（Cancel-based Recovery）、基于改变的恢复（Change-based Recovery）和基于日志序列的恢复（Log sequence recovery）。
基于时间点的恢复最为常用。当然更多情况下，我们可能面对的是单个数据文件或表空间的损坏。对于这类故障，可以针对单个文件或表空间进行完全恢复，恢复通常并不会影响整个数据库的运行，受影响可能只是和故障表空间相关的应用。
