Oracle其它情况的恢复-CSDN博客

数据库特殊情况的恢复

1. 联机Redo日志损坏与恢复

对于正常关闭的数据库来说，关闭前会执行一个检查点以保证数据库的一致性，重启之后，联机日志是是否存在都不会导致数据的丢失。然而，如果是非正常关闭的数据库，重启之后会执行实例恢复的过程，如果实例恢复过程需要的UNDO活Redo日志丢失，那么就可能造成数据的不一致和数据的丢失。

a. 连接Redo日志损坏的4种情况

联机Redo日志文件的损坏有以下4中情况：

情况1 非当前日志损坏，正常关闭数据库。

情况2 非当前日志损坏，非正常关闭数据库。

情况3 当前日志损坏，正常关闭数据库。

情况4 当前日志损坏，非正常关闭数据库。

b. 处理方法

1）情况1和情况2的处理方法

情况1和情况2的处理方法一样，直接把日志文件清除即可：

SQL> alter database clear logfile group 3;

2）情况3的处理方法

在SQLPLUS中执行以下的SQL语句以RESETLOGS模式重新打开数据库：

SQL> startup mount;

SQL> recover database until cancel;

SQL> alter database open resetlogs;

3）情况4的处理方法

这种情况会导致联机Redo日志中的一部分已提交的数据丢失，实例恢复中的前滚操作不能成功执行，回滚操作也无法执行，这也会导致部分数据的丢失。处理方法是强制打开数据库或通过备份执行介质不完全恢复。

2. 数据文件脱机与恢复

数据库的脱机包括数据文件的脱机和表空间的脱机，数据文件的脱机和表空间非正常脱机在下一次执行联机命令之前都无需先执行介质恢复操作，介质恢复成功才能联机成功。

数据文件添加到表空间之后不能再被删除，也没有语法支持这么做，如果不想使用该数据文件，唯一的方法是将数据文件设置为OFFLINE状态。执行以下步骤将数据文件设置为OFFLINE状态：

1）如果是归档模式可以执行如下SQL语句设置数据文件的状态为OFFLINE：

SQL> alter database datafile ‘xxx.dbf’ offline;

2）如果是非归档模式执行以下SQL语句将数据文件状态设置为OFFLINE：

SQL> alter database datafile ‘xxx.dbf’ offile drop;

即使数据文件脱机，数据文件相关的数据字典信息、元数据信息依然存在，当表空间被删除后，相关数据文件的信息才会被清除。Drop tablespace只是清空Oracle数据字典信息，即使数据文件不存在也可以正常的drop表空间。对于数据文件的脱机，在设置该数据文件OFFLINE的时候都需要对该数据文件执行介质恢复。

如果在非归档模式下使用OFFLINE drop使数据文件脱机，这就意味着该数据文件可能无法再恢复到online状态，原因在于非归档模式下可能没有足够的日志文件在执行online的时候完成介质恢复。如果数据文件脱机之后日志没有发生切换，所有需要的日志还依然存在的话，那么非归档模式下数据文件的脱机也可以再次变成online状态。