数据库失败的类型分为几大类。对于每种失败来说，Oracle都会提供适当的解决方法。
所有失败类型最好被记录在一个服务级别协议内，同时在程序手册中还要记录解决失败的相关步骤。
第四种失败类型：用户错误
就Oracle而言，所关心的是事务。对于DML错误来说，用户在提交之前发现错误时仍然有机会回滚错误的语句。但是对于DDl语句来说，用户是无法回滚错误的语句。
因为，commit被内置到DDL语句中。
解决用户错误的理想方式是首先防止这些错误的出现。培训用户只是其中的一部分工作，不过最重要的是设计软件。从而使任何用户进程都不允许用户执行不存在where子句的update语句。然而设计最完美的软件也没法防止用户发出与指定业务不相符的sql语句。Oracle为修正用户错误的dba提供了许多可用的方法，不过使用这些方法通常极为困难，尤其是用户错误在一段时间内未被报告时更是如此。可能的技术包括闪回查询，闪回删除，闪回数据库和不完全恢复。
闪回查询时针对过去某时存在的数据库所运行的查询。通过使用撤销数据，可以只为当前会话构造读一致性的数据库。
如下：有一位用户不小心删除了emp表中的所有行，并提交了删除操作，那么随后通过针对5分钟之前的表执行子查询检索这些行。
SQL> delete from emp;
15 rows deleted.
SQL> commit;
Commit complete.
SQL> select count(*) from emp;
COUNT(*)
----------
0
SQL> insert into emp (select * from emp as of timestamp(sysdate-5/1440));
15 rows created.
SQL> select count(*) from emp;
COUNT(*)
----------
15
（2）利用闪回删除来恢复被删掉的表
如下:
SQL> drop table emp;
Table dropped.
SQL> select count(*) from emp;
select count(*) from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> flashback table emp to before drop;
Flashback complete.
SQL> select count(*) from emp;
COUNT(*)
----------
15 |
对于撤销用户错误来说，不完全恢复与闪回数据库是作用更为显著的方法。使用上述任一种方法，整个数据库会返回发生错误前的时刻。前面介绍的其他方法在保持数据库其他部分不发生变化的情况只撤销错误的事务。但是，一旦执行了数据库的不完全恢复或闪回操作，就会失去从返回到的时刻开始的所有工作，而不仅仅失去错误的事务。