使用Deepseek进行Oracle恢复,引起重大故障---惜分飞

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

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

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

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

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

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

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

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