数据库中的数据删除后还能恢复吗

数据库中的数据被删除后，可以恢复。但至少需要满足两个条件：

1、在误删之前，至少有完整备份之前的数据库。

2、数据库的恢复模式（Recoverymode）是“完整（Full）”。

只有满足这两个条件，才可以恢复数据库中误删的数据。

针对这两个前提条件，有三种方式可以恢复数据：

方式一：如果，这两个前提条件都满足，可以通过SQL语句进行数据恢复，而且只需三步即可恢删除的数据，无需第三方工具。

方式二：当不满足第一个条件，而满足第二个条件时，需要借助第三方工具，才能恢复数据。

方式三：如果两个条件都不满足，数据则无法恢复。所以，一定将数据库的恢复模式，调整为“完整（Full）”。

flashback table与9i的flashback query相似，利用undo信息来恢复一个或者一些表到现在以前的一个时间点（一个快照）。Undo相关参数如下，需要确保AUM与足够的retention值。

SQL>show parameter undo

NAME TYPE VALUE

------------------------------------

undo_management string AUTO

undo_retention integer 900

undo_tablespace string UNDOTBS1

首先要说明的是，flashback table不等于flashback query，所谓query，仅仅是查询以前的一个快照点而已，并不改变当前表的状态，而flashback table不一样，将改变当前表及附属对象一起回到以前的时间点。

其实9i的flashback query在10g中也有了新的变化，10g中可以简单的利用以下语句实现flashback query，而不再需要象9i那样需要调用DBMS_FLASHBACK包。

SELECT * FROM TABLENAME AS OF TIMESTAMP

TO_TIMESTAMP('2003-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')

WHERE ……

10g的flashback table有如下特性

· 在线 *** 作

· 恢复到指定时间点或者SCN的任何数据.

· 自动恢复相关属性，如索引，触发器等

· 满足分布式的一致性

· 满足数据一致性，所有相关对象将自动一致

语法为：

FLASHBACK TABLE tablename TO TIMESTAMP (JUL-07-2003, 02:33:00)

FLASHBACK TABLE employee TO SCN 123456

FLASHBACK TABLE t1 TO TIMESTAMP '2003-03-03 12:05:00' ENABLE TRIGGERS

其中ENABLE TRIGGERS表示触发器恢复之后为enable状态，而默认为disable状态。

注意：如果需要flashback一个表，需要保证

需要有flashback any table的系统权限或者是该表的flashback对象权限。

需要有该表的SELECT, INSERT, DELETE, ALTER权限

必须保证该表ROW MOVEMENT

下面，我们用一个详细的例子来说明这个过程：

16:16:51 SQL>create user flash identified by flash

User created.

16:17:04 SQL>grant connect,resource to flash

Grant succeeded.

16:17:19 SQL>connect flash/flash

Connected.

16:26:35 SQL>create table t1 as select * from all_objects

Table created.

16:37:24 SQL>create table t2 as select * from t1

Table created.

16:37:35 SQL>select count(*) from t1

COUNT(*)

----------

38949

16:37:43 SQL>select count(*) from t2

COUNT(*)

----------

38949

16:38:06 SQL>create index inx_test1 on T1 (object_name)

Index created.

16:39:55 SQL>create index inx_test2 on T1 (object_id)

Index created.

16:40:47 SQL>select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual

TO_CHAR(SYSDATE,'YY

-------------------

2004-04-06 16:41:18

以上获得一个时间戳，假定我们要恢复该表到这个时间，那么以下对该表的 *** 作都将被前滚。

16:41:18 SQL>drop index inx_test1

Index dropped.

16:41:33 SQL>delete from t1

38949 rows deleted.

16:41:46 SQL>commit

Commit complete.

16:41:49 SQL>truncate table t2

Table truncated.

在以上的 *** 作中，我们delete一个表，然后truncate一个表，下面，我们将来看看flashback table的效果，能恢复到什么程度

16:37:55 SQL>ALTER TABLE t1 ENABLE ROW MOVEMENT

Table altered.

16:38:03 SQL>ALTER TABLE t2 ENABLE ROW MOVEMENT

Table altered.

16:43:10 SQL>flashback table t1 TO TIMESTAMP to_timestamp('2004-04-06 16:41:18','yyyy-mm-dd hh24:mi:ss')

Flashback complete.

16:43:49 SQL>flashback table t2 TO TIMESTAMP to_timestamp('2004-04-06 16:41:18','yyyy-mm-dd hh24:mi:ss')

flashback table t2 TO TIMESTAMP to_timestamp('2004-04-06 16:41:18','yyyy-mm-dd hh24:mi:ss')

*

ERROR at line 1:

ORA-01466: unable to read data - table definition has changed

我们可以发现，执行delete *** 作的表是可以恢复的，而执行truncate *** 作的表是不可以恢复的，这正好也说明了flashback table利用undo的结论。

看看我们的结果：

SQL>select count(*) from t1

COUNT(*)

----------

38949

SQL>select count(*) from t2

COUNT(*)

----------

0

SQL>select t.index_name from user_indexes t where t.table_name='T1'

INDEX_NAME

------------------------------

INX_TEST2

还可以看到，对于drop的索引，也是没有办法恢复的，因为drop并不记录undo，所以所谓索引的恢复，仅仅是相关索引树的改变而不能找回删除掉的索引。

1, 如果你有比较新的备份文件，可以将备份恢复到另外一台机器上，然后将对应表导入到当前库；

2，如果你的日志文件还没有被覆盖，将日志文件copy出去，先备份一下，找个读取sqlserver日志的工具，从日志文件中逐条记录恢复。

---