oracle 导入dmp_oracle异常恢复（一）dul和bbed的使用-CSDN博客

本文链接：https://blog.csdn.net/weixin_39723899/article/details/111285523

日常工作中，我们经常会使用各种各样的工具进行辅助，但实际上工具本身的使用一般都很简单，比熟练使用工具更重要的是理解他的实现原理。本篇文章笔者将介绍与oracle异常恢复相关的两个工具的使用以及他们的实现原理(bbed和dul)。申明一点：既然说是异常恢复，所以本文中默认数据库是没有备份的也未开启归档模式。在进入正题之前，我们先来试想几个问题：如果在生...

摘要由CSDN通过智能技术生成

日常工作中，我们经常会使用各种各样的工具进行辅助，但实际上工具本身的使用一般都很简单，比熟练使用工具更重要的是理解他的实现原理。本篇文章笔者将介绍与oracle异常恢复相关的两个工具的使用以及他们的实现原理(bbed和dul)。

申明一点：既然说是异常恢复，所以本文中默认数据库是没有备份的也未开启归档模式。

在进入正题之前，我们先来试想几个问题：

如果在生产环境中truncate了一张表，还能恢复吗？如果可以该如何恢复？
如果在生产环境中offline了一个数据文件，等想再次online的时候，发现介质恢复所需要的redo log已经被覆盖了，还能恢复吗？如果可以该如何恢复？
如果在生产环境中误删了一个业务用户，还能恢复吗？如果可以该如何恢复？

对于第一个问题，答案当然是肯定的(可能会丢失数据，也可能不会丢)，其实回答这个问题之前我们首先需要知道truncate这个动作到底都做了些什么，其中最重要的一步就是清空段的extent map(extent map中记录了哪些文件哪些块是属于这张表的)，而truncate的动作只是将extent map的映射关系给清除了，而实际的物理数据文件以及数据块中的数据都还是存在的，这些块在被重用之前并没有被清除，所以这些块还没有被重用就还能被恢复。这里插一句，其实我们可以在truncate表的时候加相应参数以达到不同的效果，例如drop storage(清空数据，只保留一个分区结构)、reuse storage(清空数据，段结构不回收)以及drop all storage等，这里不再展开。

既然我们已经知道了数据能否恢复的关键前提(数据块未被重用)，那么当我们遇到这种情况的时候，首要的任务就是将该表所在的相关表空间置为read only。

alter tablespace tablespace_name read only;