« DBID的获取 与 控制文件中有什么？ | Blog首页 | 2010: Oracle发布第四财季财报 SUN带来盈利 »

Oracle数据恢复:强制Resetlogs的可能数据损失

很多时候，在强制打开数据库之后，比如使用了_allow_resetlogs_corruption等隐含参数，可能会导致数据库丧失一致性，损坏部分数据，如果损失的是部分DML数据，则数据库可能仍然可以运行良好，但是如果损失的是元数据，则可能数据库会出现一些其他的异常，当时这些异常也仍然是可以修复的，只是成本或代价会比较高昂。

最近的一则案例中，恢复数据之后，用户动态创建的某些临时表出现问题，无法成功导出，这就是强制Resetlogs的后果之一。

导出时的部分日志信息参考如下：

. . 正在导出表                     TEMP_347064
EXP-00007: 字典未显示 EYGLE1100.TEMP_347064 的列
. . 正在导出表                     TEMP_347065
EXP-00007: 字典未显示 EYGLE1100.TEMP_347065 的列
. . 正在导出表                     TEMP_347066
EXP-00007: 字典未显示 EYGLE1100.TEMP_347066 的列
. . 正在导出表                     TEMP_347067
EXP-00007: 字典未显示 EYGLE1100.TEMP_347067 的列
. . 正在导出表                     TEMP_347068
EXP-00007: 字典未显示 EYGLE1100.TEMP_347068 的列
. . 正在导出表                     TEMP_347069
EXP-00007: 字典未显示 EYGLE1100.TEMP_347069 的列
. . 正在导出表                     TEMP_347070
EXP-00007: 字典未显示 EYGLE1100.TEMP_347070 的列
. . 正在导出表                     TEMP_347071
EXP-00007: 字典未显示 EYGLE1100.TEMP_347071 的列

所以一般在次情况下打开的数据库，最好进行exp备份后，进行数据库重建（除非你确实判断，无特殊异常，或者可以处理相关异常）。

仅供参考。

-The  End-

By eygle on 2010-06-30 15:56 | Comments (0) | Backup&Recovery | 2567 |

ExportRecovery