点击上方蓝字关注我们～
我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora.com” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
距离上篇《恶意程序清空TAB$（ORA-00600 16703）表恢复系列一：TAB$表清空报错错误汇总》文章已经半个月，上篇中总结了delete tab$相关的报错，也说此类错误是“人为导致的错误”。应网友们的要求，这次简单阐述一下“人为导致的错误”的过程。
报错的代码如下：
ORA-00600错误会在后台自动生成一个errorstack和incident信息。
Incident 8553 created, dump file: oracle/app/oracle/diag/rdbms/rescureora/rescureora/incident/incdir_8553/rescureora_ora_32197_i8553.trc
使用关键字进行搜索：
grep "Current SQL Statement for this session" /oracle/app/oracle/diag/rdbms/rescureora/rescureora/incident/incdir_8553/rescureora_ora_32197_i8553.trc
objno为20的对象的ddl语句在bootstrap$中，是数据库在启动的时候自动初始化的。
CREATE TABLE ICOL$("OBJ#" NUMBER NOT NULL,
"BO#" NUMBER NOT NULL,
"COL#" NUMBER NOT NULL,
"POS#" NUMBER NOT NULL,
"SEGCOL#" NUMBER NOT NULL,
"SEGCOLLENGTH" NUMBER NOT NULL,
"OFFSET" NUMBER NOT NULL,
"INTCOL#" NUMBER NOT NULL,
"SPARE1" NUMBER,
"SPARE2" NUMBER,
"SPARE3" NUMBER,
"SPARE4" VARCHAR2(1000),
"SPARE5" VARCHAR2(1000),
"SPARE6" DATE)
STORAGE ( OBJNO 20 TABNO 4) CLUSTER C_OBJ#(BO#) ;
查看ALERT日志，发现一个诡异的创建语句，可以肯定是非业务SQL语句，如下：
create table ORACHK82F6966E053076FA8C09E8A
tablespace system
as select * from sys.tab$;
结论：
$ORACLE_HOME/rdbms/admin/prvtsupp.plb文件被人恶意修改。
解密后的内容如下：
也就是当数据库创建的时间大于300天后，如将数据库重启，那么在启动后就会触发DBMS_SUPPORT_DBMONITOR，此时备份sys.tab$的内容，再将tab$的内容全部删除。此时数据库执行任何查询命令就将返回0行数据库，如果将数据库再次重启，那么此时就会触发上面的报错。
解决方案一：在本次中遇到的这个案例环境有点特殊，数据库运行在windows平台，并且数据库运行在阿里云上，更巧的是他们dba有个好习惯，每次要重启数据库时都对整个虚拟机做一次快照，数据库是放在D磁盘，操作系统是放在C磁盘，并且C,D对应不同的阿里云磁盘。此环境非常特殊，还原的方法也非常简单，但是也是有一定讲究的。步骤如下：
利用快照闪回C盘。
禁用Oracle服务随操作系统自动启动。
利用快照闪回C盘。
创建init参数文件，引用spfile文件，再加上'_system_trig_enabled' =false;
启动Oracle服务
启动数据库，并删除触发器，关闭数据库
删除init参数文件
重启数据库。
业务正常连接，并且无任何数据丢失。
虽然整个恢复方案是非常简单的，这里分享出来，只是想和大家一起分享一个思路，数据库的恢复因环境而变，没有固定的方法。在做恢复时，我们需要对环境了解清楚。很多时候，我们是花了55分钟来思考为什么后，却只需要5分钟就可以解决问题。如果没有找到问题根源，可能我们做了2个小时也仍不能解决问题。
也许很多人会说，这个案例太特殊了，不具备学习的价值。确实它很特殊，但是已经在生产环境遇到几次了。
恢复的方案很多，最简单、最可能的方法就是最好的方案。
下周我们将继续分享解决方案二，也是一个技巧的方法。后续我们会继续分享解决方案三：通过bbed修改块来修复。敬请期待。
ps：大家可以扫描下方的微信二维码，添加我们的学习小助手，一起进群相互交流和学习～
Oracle恢复实录
rescureora.com
欢迎扫码关注
让我知道你在看
