使用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$这个表记录.让现场技术人员再次确认这个库的所有操作,最后确认在他不知情的情况下,有另外的技术人员上来进行了类似操作

---

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

delete from ts$ where name='UNDOTB1';
delete from seg$ where ts#=2;

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

---

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

---

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

---

在这里温馨提醒,虽然现在的ai比较发达,很多问题可以直接在上面问出来答案,但是需要对这些答案有一个判断能力,不能他说啥你就执行啥,特别是数据库非常规恢复这种不可逆而且可能引起重大事故的高风险性操作需要谨慎和做好回退方案.