oracle故障恢复,Oracle数据库故障时恢复原理

做好了备份之后，在故障时就需要通过备份来进行恢复。

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)。

基于时间点的恢复最为常用。当然更多情况下，我们可能面对的是单个数据文件或表空间的损坏。对于这类故障，可以针对单个文件或表空间进行完全恢复，恢复通常并不会影响整个数据库的运行，受影响可能只是和故障表空间相关的应用。