如何将勿操作truncate的表恢复回来
由于对于truncate命令没有回滚方法来还原,因此就需要对数据库进行恢复操作以将数据恢复回表中。
本文中将给出truncate命令后的恢复思路及步骤:
RECOVER DATABASE UNTIL TIME 恢复步骤方案
注意: 在开始使用旧备份进行数据库恢复前,对当前数据库做好备份
- 当时是否有表的export dump文件可用?
a. 有 -> import导入文件还原表数据
b. 没有 -> 跳转至步骤2 - 数据库是否在archivelog模式下?
a. 是 -> 跳转至步骤3
b. 不是 -> 跳转至步骤4 - 数据库在归档模式下。那么可以使用备份归档至数据库某个表被truncate前的时间点。
a. 恢复数据库备份至另一个位置。
b. 使用RECOVER DATABASE UNTIL TIME .....将数据库recover到truncate之前某个时间点。
c. 从恢复的数据库中导出所需的表数据。
d. 将数据import会原库对应被truncate数据的表中。
e. 工作已经完成,将恢复的库删掉即可。 - 数据库不在归档模式下, 因此没有方法将数据库恢复到truncate之前的时间点。
你需要联系Oracle或更第三方专业Oracle数据恢复专家来帮忙处理。
你也可以使用FLASHBACK来回滚到TRUNCATE前以找到所需恢复的数据。
下面的步骤将使用FLASHBACK来将数据库恢复到表TRUNCATE之前,然后使用数据库恢复方法将数据库回到当前时间点。
- 给表MYOBJ插入数据行 - 这表会在之后被truncate
- SQL> insert into scott.myobj select * from all_objects;
- 50496 rows created.
- SQL> /
- 50496 rows created.
- SQL> select count(*) from scott.myobj;
- COUNT(*)
- ----------
- 100992
- 获取SCN - FLASHBACK将需要回到这个时间点
- SQL> select current_scn from v$database;
- CURRENT_SCN
- ---------------------
- 15633908021
- TRUNCATE表
- SQL> truncate table scott.myobj;
- Table truncated.
- SQL> select count(*) from scott.myobj;
- COUNT(*)
- ----------
- 0
- 同时我们更新数据库中其它表以验证在FLASHBACK后再进行的数据库恢复将数据库回到最新状态。
- SQL> insert into scott.myobj2 select * from scott.myobj2;
- 356874 rows created.
- SQL> /
- 713748 rows created.
- SQL> commit;
- Commit complete.
- 关闭数据库并进行FLASHBACK
- SQL> shutdown immediate;
- Database closed.
- Database dismounted.
- ORACLE instance shut down.
- SQL> startup mount;
- ORACLE instance started.
- Total System Global Area 469762048 bytes
- Fixed Size 2084880 bytes
- Variable Size 377491440 bytes
- Database Buffers 83886080 bytes
- Redo Buffers 6299648 bytes
- Database mounted.
- SQL> FLASHBACK DATABASE TO SCN 15633908021;
- Flashback complete.
- 以只读方式打开数据库并导出被误truncate的表数据,导出的数据会在数据库recover后被导回去。
- SQL> alter database open read only;
- Database altered.
- SQL> select count(*) from scott.myobj;
- COUNT(*)
- ----------
- 100992
- SQL> quit
- Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
- With the Partitioning, OLAP, Data Mining and Real Application Testing options
- crashdb:/u03/oradata/crashdb/arch> exp file=scott.dmp tables=myobj
- Export: Release 10.2.0.4.0 - Production on Fri Feb 6 09:53:00 2009
- Copyright (c) 1982, 2007, Oracle. All rights reserved.
- Username: scott
- Password:
- Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
- With the Partitioning, OLAP, Data Mining and Real Application Testing options
- Export done in US7ASCII character set and AL16UTF16 NCHAR character set
- server uses WE8ISO8859P1 character set (possible charset conversion)
- About to export specified tables via Conventional Path ...
- . . exporting table MYOBJ 100992 rows exported
- Export terminated successfully without warnings.
- 关闭数据库后,重新mount库并进行recover
- SQL> shutdown immediate
- Database closed.
- Database dismounted.
- ORACLE instance shut down.
- SQL> startup mount;
- ORACLE instance started.
- Total System Global Area 696254464 bytes
- Fixed Size 2086616 bytes
- Variable Size 184551720 bytes
- Database Buffers 503316480 bytes
- Redo Buffers 6299648 bytes
- Database mounted.
- SQL> recover database;
- Media recovery complete.
- SQL> alter database open;
- Database altered.
- 正如所看到到,在数据库recover后,被truncated的表继续为0行数据,我们可以将已经导出的表数据导入恢复即可。
- SQL> select count(*) from scott.myobj;
- COUNT(*)
- ----------
- 0
- 作为对比,我们可以看到recover后的scott.myobj2表行数。
- SQL> select count(*) from scott.myobj2;
- COUNT(*)
- ----------
- 713748