摘要：一套运行5年多的Oracle RAC集群因异常导致节点2重启，触发了tab$表被清空，节点1出现大量ORA-600错误。分析发现节点2首次重启后数据库开始报错，第二次重启时出现ORA-60016703错误，确认是tab$表被恶意脚本清空所致。由于节点1保持open状态，恢复工作较为简单：从备份表中恢复tab$数据，清理恶意脚本后重启两个节点。这次成功恢复的关键在于故障发生后及时保留现场，未重启仍运行的节点1，为数据恢复创造了有利条件。该案例展示了在数据库故障中保持冷静判断的重要性。

客户正常关闭数据库,然后启动报ORA-600 kokiasg1错误,通过对启动分析确认是由于IDGEN1$序列丢失导致,修复该故障之后,数据库启动成功,但是后台大量报ORA-600 12803,ORA-600 15264等错误,业务用户无法登录.经过深入分析,发现数据库字典obj$中所有核心字典的序列全部被删除,但是在seq$中这些对象的obj#记录还存在.初步怀疑是有人恶意删除了obj$中字典核心序列对象导致.

数据库文件被加密,扩展名类似:.[[dataserver@airmail.cc]].sstop,通过工具进行坏块检测确认破坏数据文件三段,每段8个block。根据经验可以确认,数据文件前面8个block肯定没有业务数据(主要是文件头信息和位图信息),可以使用Oracle数据文件勒索加密恢复工具对其文件头进行构造。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。

通过底层对磁盘进行分析,发现备份的磁盘头均以损坏,通过深入分析确认f1b1在sdb磁盘的第10个au上,通过相关信息,使用dul工具加载磁盘组,并分析元数据信息,发现恢复数据需要的元数据都可以正常加载。1)asm disk 加入到vg,并分配给lv之后,立刻停止写入操作,避免了因为写入数据而覆盖asm 磁盘的带来的风险。客户在不清楚磁盘被asm disk使用的情况下,直接分区做pv,加入到vg中并且分配给了lv,导致数据库异常。4)是云环境的ssd磁盘,没有触发trim功能。

​该软件是惜分飞（https://www.xifenfei.com）开发，仅用来查看和修改Oracle数据库SCN(System Change Number),主要使用在数据库因为某种原因导致无法正常启动的情况下使用该工具进行解决.特别是Oracle新版本中使用隐含参数,event,oradebug等方法无法推进Oracle SCN的情况下，使用该工具能够快速修改SCN,实现数据库启动成功.​

这个相对比较简单,对异常undo进行处理,cdb和pdb都open成功,使用数据泵把数据迁移到新库,完成本次恢复(比较幸运,硬件故障的库直接迁移成功,没有报其他错误)硬件故障,客户自行强制resetlogs库,报ORA-600 kcbzib_kcrsds_1错误。处理好该错误之后,数据库在open pdb的时候报ORA-600 4193错误。这个错误处理过多次一般是由于scn异常导致,以前部分类似文章。

然后直接open数据库,并且导出数据,实现数据库非常完美的恢复(这个是目前除直接解密之外最好的恢复效果,没有之一)对于这种级别的损坏,可以通过我开发的Oracle数据文件勒索加密恢复工具直接重构文件头。8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果。2.登录口令要有足够的长度和复杂性，并定期更换登录口令。9.保存良好的备份习惯，尽量做到每日备份，异地备份。4.定期检测系统和软件中的安全漏洞，及时打上补丁。