时隔半年之久，ORACLE表记录恢复案例一则

    项目组的一位同事打来电话，说这一次客户把事情捅到老总那里去了。
    我问怎么回事，他说：在客户现场，项目数据库中某张记录着重要信息的表的记录全没了，问能不能恢复？
    我问什么时候没的。他说2015年11月的时候没的（乖乖，现在是2016年6月7日，半年了已经）。并且说：当时那边驻场的项目组的同事要离职，就没有把这事放心上，迟迟未处理。现在时间过去这么久，交接的人也早上岗了，可是问题仍然不能解决，客户怒了。
    我让他查一下数据库是否开启了归档，得到的答案是：没有。
    没有归档，通过日志来恢复肯定是不可能的。而时间又过去了这么久，如果是删除了记录，通过闪回肯定也没戏。而如果是DROP了表，在没有清空ORACLE回收站的情况下，倒是可以恢复。可是根据他的描述，不可能是执行DROP导致的呀！DROP了之后，查询会报错——表或视图不存在，而不是查询到空记录。
    然而，不管怎么说，我还是得去现场看看是什么情况。
    到了现场，我首先查了一个回收站 ：select * from user_recyclebin where original_name='TBIDM' (表名为TBIDM)，查询到的OBJECT_NNAME为BIN$2N+bpyN9QjOgqEBKhJkjPA==$0 。
    竟然真的有记录，CREATETIME为2010年，DROPTIME为2015年11月18日。什么？2015年11月，这个时间不就是记录没的时间点吗！
    我赶紧又去查一查当前T BIDM对象的一些信息：select * from user_objects where object_name='TBIDM' , CREATED字段为2015年11月18日。天啦，它的创建时间不就紧接着上个同名对象的删除时间嘛！
    至此，我作了一个大胆的假设：TBIDM表被“有意”或无意地删除，而后又创建了一个同名同结构的表。如果是这样的话，恢复起来就简单了：
    1）先将TBIDM表改名：
         alter table TBIDM rename to TBIDM_20160607;
    2）将回收站内的TBIDM的闪回：
         flashback table "BIN$2N+bpyN9QjOgqEBKhJkjPA==$0" to before drop;
    至此，TBIDM表就被恢复了。但这仍然有一个问题，由于作业是持续的，2015年11月到2016年6月这期间入库的数据还在被改名的TBIDM_20160607表中。所以，接下来，只需要将TBIDM_20160607表的记录插入到TBIDM表中即可：
    insert into TBIDM select * from TBIDM_20160607

    至此，恢复结束。客户验证后，表示数据已经全部回来了。问题是解决了，可以我还要再多说几句。可能大家注意到我上文第10段把“有意”两个字引起来了。为什么呢？因为我不觉得这是有意为之的行为。虽然那位同事当时正在办离职，但我不觉得这是一种刻意行为。那既然不是刻意的，通过前端应用程序不可能执行删除表的动作，删除是发生在什么时候呢？如果大家用过PL/SQL Developer工具执行过导入导出，一定记得，在import tables工具中，提供了3种导入方式，分别为 Oracle Import 、SQL Inserts、PL/SQL Developer 。其中 ，PL/SQL Developer 是导入PDE格式的转储文件，使用该方式导入，有一些可选项，如下图：
     
    注意到没有，有一个可选项 “Drop tables“ ，即在导入数据之前，先将同名的表删除掉。本例中出现的删除操作，可能就是无意间勾选了该选项导致的。当然，PL/SQL Developer 只是举一个例子，尚不能肯定它就是真实原因，其它如脚本中带有 DROP TABLE XX 的也会导致同样的情况。希望能通过此例，让大家警惕工具或脚本潜在的风险，对数据库的操作一定要非常警惕。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31340387/viewspace-2118123/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31340387/viewspace-2118123/