www.sosit.com.cn

PLSQL恢复删除的数据：一次真实的抢救过程

上周五快下班的时候，一个客户的电话打了进来，语气很急：“我刚在PL/SQL Developer里把一张核心业务表删了，DROP TABLE……没有备份，能救回来吗？”我一边让他别慌，一边打开远程。说实话，DROP操作比DELETE难搞得多，但也不是死路一条。今天这篇就围绕plsql恢复删除的数据，把常见的场景、判断逻辑和操作手法捋一遍，可能有些跳跃，你跟着我的思路走就行。

技王数据恢复

先判断数据还能不能救：闪回技术是首选

在PL/SQL Developer里误删数据，很多人第一反应是去回收站（Recyclebin）里找。但注意：DROP TABLE默认会进回收站，前提是表空间设了回收站功能（默认开启）。如果是PURGE掉的，或者直接DELETE COMMIT了，回收站就没用。 技王数据恢复

我遇到过一个案例：开发人员用PL/SQL Developer的“删除行”功能清空了整张表，然后立刻点击了提交。当时表里一共20万行数据，老板就在身后站着。他问我能不能恢复，我看了下时间，距离提交过了10分钟。幸好Oracle有闪回查询（Flashback Query）功能，在undo表空间还没被覆盖的情况下，可以直接查过去某个时间点的数据。 www.sosit.com.cn

核心判断：如果是DELETE操作且提交时间短，闪回查询是最快的方法。如果是DROP TABLE未PURGE，用闪回删除（Flashback Drop）直接恢复。如果已经PURGE或经过大量DML操作覆盖了undo，就需要更底层的工具，这时候不得不找专业公司，比如我们之前用技王数据恢复的底层扫描做过类似案例。

具体操作步骤（以PL/SQL Developer为例）

场景一：DELETE后闪回查询

1. 在PL/SQL Developer的SQL窗口执行：SELECT * FROM 表名 AS OF TIMESTAMP TO_TIMESTAMP('2025-03-21 17:30:00', 'YYYY-MM-DD HH24:MI:SS'); 时间点要选在删除之前。
2. 如果查询成功，将结果插入原表：INSERT INTO 表名 SELECT * FROM 表名 AS OF TIMESTAMP … ;
3. 如果报错“snapshot too old”，说明undo空间已被覆盖，进入下一方案。

有个小技巧：如果不确定精确时间，可以用SELECT * FROM 表名 VERSIONS BETWEEN … 尝试多个版本。PL/SQL Developer的网格在显示大结果集时可能卡，建议在查询中添加ROWNUM控制。 www.sosit.com.cn

场景二：DROP TABLE（未PURGE）闪回删除

1. 在SQL窗口执行：SHOW RECYCLEBIN; 查看回收站。
2. 如果看到被删的表，直接恢复：FLASHBACK TABLE 原表名 TO BEFORE DROP; 注意：如果同名表已存在，需要重命名：FLASHBACK TABLE "回收站中的名称" TO BEFORE DROP RENAME TO 新表名;
3. 恢复后检查数据完整性，索引、约束可能丢失部分，需要手动重建。

有一次我帮客户恢复一个被DROP的日志表，闪回成功后表结构完整，但数据少了几行——因为表里有自增触发器，回收站恢复时触发器会失效。这个坑要记一下。

技王数据恢复

场景三：PURGE后的深度恢复（需要底层工具）

如果已经执行了PURGE TABLE或者PURGE RECYCLEBIN，闪回就无能为力了。这时候数据仍然存在于数据文件中，只是变成“未分配”状态。需要扫描数据文件的块，识别被删除的记录。plsql恢复删除的数据到这个阶段，常规SQL已经没用，只能靠专业软件或人工解析。

技王数据恢复

曾经有个极端案例：客户误PURGE后，又执行了ALTER TABLESPACE添加数据文件的操作，导致部分数据块被覆盖。我们当时用技王数据恢复工具，配合Oracle的bbed（内部块编辑器）分析了20多个数据文件，最终找回约70%的数据。这种操作不建议自己尝试，除非你对Oracle内部结构非常熟悉，否则一个写错就可能让数据库崩溃。

注意事项与常见误区

• 禁止直接重启数据库：很多人一着急就关库重启，但其实重启可能清空某些内存缓冲区，导致undo信息丢失。应该先做静态拷贝。
• PL/SQL Developer与SQL*Plus的差异：在PL/SQL Developer里执行闪回语句时，如果使用“命令窗口”和“SQL窗口”可能影响绑定变量，建议直接用SQL窗口。
• 闪回时间点估算：如果你不知道精确删除时间，可以查看alert日志或v$sqlarea中最近的高消耗SQL。有一次我通过监听日志找到了一条“DELETE FROM ...”的记录，时间精确到秒。
• 表空间大小与undo retention：如果undo表空间设置了guarantee，可能会保留更久的数据。但默认情况下，undo在空间紧张时会被覆盖。

写到这里我想起一个反面教材：有个新手DBA，误删了分区表的一个分区，他用ALTER TABLE … DROP PARTITION之后无法闪回，以为分区和普通表一样能进回收站——实际上分区DROP后直接释放段，不经过回收站。后来他用了一种叫“TSPITR”的表空间时间点恢复技术，但因为数据文件受到破坏，还是失败了。找到我们，我们用技王数据恢复提供的“基于Redo日志解析”服务，从归档日志里重建出所有数据。这个案例说明，plsql恢复删除的数据绝不能一概而论，必须根据删除类型选择正确的路线。

故障判断流程（简易决策树）

为了方便你快速定位，我画一个非正式的决策流程：

1. 是DROP TABLE 还是 DELETE + COMMIT？——如果是DROP，先看回收站（SHOW RECYCLEBIN）；如果是DELETE，直接跳到第3步。
2. 回收站有目标表吗？——有则用FLASHBACK TABLE；没有则可能被PURGE，转底层恢复。
3. DELETE后能否执行闪回查询？——可以就INSERT INTO；报“snapshot too old”则考虑闪回事务查询（Flashback Transaction Query）或日志挖掘。
4. 以上都失败？——关闭数据库（防止后续写入覆盖），创建数据文件副本，使用第三方工具或联系我们。

注意：在PL/SQL Developer中，如果你使用了“提交”按钮，实际上就是COMMIT；如果不确定是ROLLBACK还是COMMIT，可以在SQL窗口执行SELECT * FROM v$transaction;看看是否有活动事务。我见过客户以为只是“预览删除”，结果PL/SQL Developer的默认自动提交触发了，直接悲剧。

经验小结：写到

这篇文章看起来有些东拉西扯，但做数据恢复就是这样——每一套方案都要根据环境动态调整。核心的plsql恢复删除的数据方法就是闪回查询、闪回删除、日志挖掘、底层扫描四板斧。如果你刚遭遇删除，建议先做以下三件事：

• 立即停止对数据库的任何写操作
• 记录当前系统时间，导出警报日志
• 快速判断删除类型（DROP/DELETE/TRUNCATE）

遇到复杂情况别自己硬来，专业的事交给专业的人。比如我们处理过一个TRUNCATE操作，TRUNCATE不支持闪回，但通过在线Redo日志+归档日志，用Logminer解析出所有INSERT语句，然后反向生成数据——前后花了3小时。这个思路目前依然是plsql恢复删除的数据中比较冷门但有效的方法。

好了，先写到这里。希望这篇带点跳跃感的经验分享能帮到你。如果你有其他问题，比如如何避免误删、如何设置默认回滚段等，欢迎交流。