用这个标题，并不夸张，其实想想都有些后怕。周日一大早，工作群里面看到消息某个数据库突然出现错误，记录流程的一个日志表不存在了，造成数据库很多表没有正常更新，原想是不是有人误删除了这个表，结果又爆出更大的问题，有接近700张表，算上索引的话有1000多个对象被人删除了，删除时间大约在昨天的20：30左右。一边客户着急的询问是否可以恢复，另一边还不清楚到底是什么人干了这种事情，于是立马赶到现场和另外一个同事商量情况。之前一天我们两个还在讨论flashback 以及在另外一个服务器上遇到的purge table的那个问题。结果不想今天这些东西都派上了用场。
首先是需要查看数据能否恢复，show parametere DB_RECOVERY_FILE_DEST_SIZE，结果是闪回空间只有2G，心理一时有些紧张，因为以前对与闪回的特性接触的不是很多，误以为2G的空间就只能保存2G的数据文件，就跟windows的回收站一样，但是经过检查user_recyclebin表，发现CAN_UNDROP字段里面基本上每个被删除的表都是YES。据同事将这个字段为YES的就可以恢复，但是有些不解的是为什么2G的闪回区可以存放这么多的数据。1000多个对象，表+索引加起来100G都超了，难道他的2G是存放user_recyclebin这个表的大小是2G么？ 先不管这么多了，还是先查一下日志，那个时间段有那些人登陆过吧， 远程连接到服务器，找到\oracle\product\10.2.0\db_1\network\log\下的listener.log文件，这个文件太大了，大约有400多M，好在服务器的性能够强劲，过了大约1分钟就打开了，然后找到8月8号的日志，对其中的晚上20：00之后的登陆IP进行重点排查，由于有监控每分钟都要扫描，因此记录量有点大，不过最好还是发现了一个很有嫌疑的IP包括机器名称，ping这个IP和机器名称都无法ping通。接着同事想到昨天他走的时候另外一个同事还在单位，于是把他叫过来，过来以后他的机器打开，IP和机器名称都ping通了，原因找到了，最后发现原来是他在写一个loop 方式的删除临时表的存储过程，结果在测试的时候把参数搞错，结果删除了大量的数据。
同事对数据赶紧进行了恢复，我则在本机上创建了大约4G的数据，然后删除，然后使用flashback table to drop before也都全部恢复了，结果除了索引和分区表无法恢复外，其余的被drop的表都恢复到了以前的被删除前的状态，真是万幸万幸啊。但是由此得到的教训也很值得考虑，我们这个同事干工作也有3年了，但是还是犯了如此的可谓低级错误，假设这个错误是在9i的版本下出现的，再加上现在很多服务器都疏于做备份，因此一旦删除就很可能是再也找不回来了，drop 表还是要特别小心才可以啊。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/12216142/viewspace-611730/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
IMP遇到的错误以及由此引发的一系列问题
下一篇：
PowerCenter 带给我的启示
请登录后发表评论
登录
全部评论
