一个恢复case,查询数据库是open状态,有一个数据文件处于offline,删除表空间报offline的文件不能读写
 

2


 

3

1


根据经验,这个是一个小问题,可能就是由于datafile 5 offline了,而这个文件是undo表空间的所以出现这样的情况,想着屏蔽下异常回滚段,或者强制online下文件就可以解决该问题.先进行第一个尝试,屏蔽异常回滚段,由于库是open状态,直接查询数据库是否有异常回滚段
 

undo_seg


无法查询到异常回滚段,这个有点不太符合常规认知,进一步核实文件和表空间信息
 

4


 

5


 

6


到这一步就发现了异常:
1. v$tablespace里面有两个undotbs1的表空间(这个肯定不对,是ctl和ts$不一致)
2. ts$中只有一个而且ts#=9没有ts#=2
3. file$中有ts#=2,这样导致ts$和file$信息不匹配,也不对
基于上述这样信息,我怀疑有人对底层字典进行了操作delete了ts$这个表记录.让现场技术人员再次确认这个库的所有操作,最后确认在他不知情的情况下,有另外的技术人员上来进行了类似操作
 

delete_ts


根据他们提供的聊天记录,以及当前数据库情况,进一步确认他们应该是执行了

delete from ts$ where name='UNDOTB1';

delete from seg$ where ts#=2;

没有对file$进行delete操作.对于这样的情况,人工删除字典,明显没有处理干净.导致数据库的任何操作都会去检查异常事务.

seg


通过清理这些异常事务,数据库可以正常操作,数据也导出成功
 

expdp


后续和当时直接进行delete 字典操作的人员沟通,他那边是根据deepseek提供的建议进行处理的

deepseek

Logo

欢迎加入DeepSeek 技术社区。在这里,你可以找到志同道合的朋友,共同探索AI技术的奥秘。

更多推荐