在2016年08月13日早上10:56分左右，一名DBA因误操作删除主营业务数据库上一个重要的模式，在10分钟内发现了该错误。第一步关闭数据库：
使用其它任何类型的关闭是毫无意义的-无论怎样都会丢失正在进行的所有工作，并且需要最小化停机时间。然后将数据库回退到10:52，如下所示：
注意，与 RECOVER DATABASE UNTIL TIME 不同的是改命令对时间戳格式的 NLS 设置很敏感。当在 READ ONLY 模式下时，可以针对删除的模式进行查询。如果发现该模式仍可用，那么或许能够恢复更多一些用户数据：
重新运行查询，发现在56分的数据又不见了：它必定是在52分到56分之间出的问题。尝试回退到55分：
如果发现模式还不可用，就往前闪回几秒。如果发现模式可用，就往后执行几秒的恢复，最大限度的靠近事发时间点。
可以重复执行闪回和恢复命令，直至找到希望的时间点，在此期间通过在只读模式下运行查询来测试。当找到满意的时间点时，执行最后一次数据库关闭并使用 RESETLOGS 打开来创建数据库第一个新前身/化身，最后就可以打开并正常使用数据库了。
这种方法可以最小化数据损失，并且仅花费几分钟。不完整恢复则可能会花费几个小时，尤其是需要多次尝试才能找到正确的时间点。
闪回数据库-限制闪回数据量
Oracle限制写到闪回日志中的数据量的算法是精心设计的，以便尽量减小对性能的影响。在一些环境中，可能发现生成的闪回数据量过大，可以在闪回日志中不记录表空间，但这样恢复过程复杂些。
默认情况下，如果启用的闪回数据库，那么会记录所有表空间的闪回数据，但可用下面命令关闭表空间闪回属性：
为了查看闪回状态，V$TABLESPACE视图中提供这样一个列：
该信息显示在一个动态性能视图中，而非数据字典视图 DBA_TABLESPACES 中，因为是通过控制文件而非数据字典启用闪回功能的。
使用如下命令重新开启：
注意，该命令只有数据库处于加载模式的时候才能执行
如果一个或多个表空间不生成闪回数据，那么在执行闪回操作之前必须使构成表空间的文件脱机。然后闪回才可以正常进行。要记住 RECOVER 将忽略脱机数据文件-这与 FLASHBACK 是相同的。
/*摘抄总结于《认证考试指南全册》*/