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

TO_CHAR(SYSDATE,'YYYYMMDDHH24:

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

2010-12-22 15:33:09

    SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss');
flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss')
*
第 1 行出现错误:
ORA-01034: ORACLE not available


SQL> startup mount;
ORACLE 例程已经启动。

Total System Global Area  171966464 bytes
Fixed Size                   787988 bytes
Variable Size             145488364 bytes
Database Buffers           25165824 bytes
Redo Buffers                 524288 bytes
数据库装载完毕。
SQL> flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss');

闪回完成。

quote]
提示成功了，将数据库打开，请注意这个restlogs！


现在让登陆进去看看结果


该表记录终于找回来了，非常激动人心吧！


除了上面说的格式问题外，还要另外注意一点，就是这个闪回的时间是有限的，要有足够的闪回空间，否则将无法将数据库闪回到时间太前的时间，比如该例子说明到早上10点就无法闪回了。

SQL> flashback database to timestamp to_timestamp('2009-03-14 10:00:00','yyyy-mm-dd hh24:mi:ss');

ERROR at line 1:

ORA-38729: Not enough flashback database log data to do FLASHBACK.

总结：本小节通过闪回了整个数据库找回了被truncate的数据，不过现实中这样闪回整个数据库的操作可能只适合在开发库和测试库，生产中做这样操作的可能性非常小，首先是闪回整个庞大的数据库要足够的空间，其次是你如果闪回了你当前失误点时刻的数据库，好象时光倒流了，但是你是并发用户数据库，别人的正常操作过程也被你给回退了。所以生产中即便要做这样的操作，也要有非常严谨的考虑和规划才开始操作。

联想与引申：本例是讲述了如何找回被truncate的表，大家想想，虽然我把delete+commit，drop表，truncate table三个最容易发生的误操作分别用闪回查询，回收站和闪回数据库三种不同的方法找回，实际上闪回数据库的方法是包含了恢复delete+commit 和drop两类，整个数据库都可以回到某个时刻，被delete+commit和drop的表能不恢复回来吗！此外被drop的表如果回收站被人清空了，估计也就不得不依赖闪回数据库了。不过闪回数据库和回收站必须依赖oracle 10g版本数据库才可以，这点要牢记！