无论是在开发测试还是运维过程中，大家都可能会出现误删除，更新bug等问题。当你想砍掉敲回车的手指，捶胸顿足，害怕的时候，你肯定希望有办法恢复这些数据。恰好oracle提供了一些强大的方法或机制，让你找到“后悔药”。根据oracle数据库的特点和提供的工具，主要有以下几种方法：使用逻辑备份使用导入工具。使用物理备份恢复数据文件，进行不完全恢复。使用dbms_logmnr包从重做日志文件中恢复。使用闪回功能恢复数据为了方便介绍使用方法，以上恢复方法将基于以下场景：系统管理员在11点使用export对整个数据库进行了逻辑备份前一天晚上，然后对所有数据文件进行了热闪回。备份。第二天上午10点，系统管理员在修改表TFUNDASSET中的数据时，由于修改语句的条件写错了，导致一批记录（千条）的ztm字段被修改为错误的值，并且它已经提交。.这张表是资产表，数据变化比较少。1.使用逻辑备份，使用导入工具恢复丢失的数据。export/import是oracle提供的数据库逻辑备份工具。本工具适用于备份数据量小、业务量小的数据库系统。因为如果前一天晚上11点用export做了一个逻辑备份，那么今天早上10点数据库意外crash时，从备份到备份这段时间的数据修改操作（包括DDL和DML）数据库崩溃会丢失。如果丢失数据中表上的数据比较稳定，也就是说表上基本没有DML操作，比如分区表中的标准码表和历史数据，那么使用import导入表可以完全恢复数据。如果表是经常变化的业务表，丢失的数据只能根据业务情况通过纸质记录或其他方式恢复。▲例子如下：这张表是资产表。相对而言，当今系统运行过程中修改的数据较少，丢失的数据量是可以容忍的，也可以通过其他方式恢复。然后就可以使用import来恢复了。方法一：1.将本表的数据备份到另一个表中：2.删除本表的记录：3.执行以下命令：在该命令中，在关键字tables中指定要导入的表名，然后ignore=y表示忽略表已存在的错误。4、导入完成后，查看表中的记录，使用适当的方法恢复当天的修改。方法二：1.将要恢复的表导入另一个用户：2.检查数据后，删除原表记录：3.然后从另一个用户的表中插入回来：4.数据时可以使用volume比较大以下方法：2.使用物理备份恢复数据文件，进行不完全恢复如果数据库运行在归档模式下，可以使用之前的数据文件备份进行恢复，然后使用归档日志回滚向前直到回滚到错误操作的时间点之前，然后重置日志文件以打开数据库。可以通过以下方法确认是否运行在归档模式下：如果是如上图，则说明运行在归档模式下。▲假设在前一天晚上11点对整个数据库进行了物理备份，可以考虑如下恢复：1.关闭数据库：由于数据库的不完全恢复必须在关闭的数据库上进行，使用一个旧的数据库备份来恢复，然后根据需要使用日志逐步前滚，而不是恢复一个新的备份然后回滚到某个时间点。通知每个客户端数据库将关闭，然后发出：数据库已关闭。数据库已卸载。ORACLE实例已关闭。2、判断错误操作的时间：可以根据运维人员的预估判断不完全恢复需要前滚停止的时间，也可以使用LogMiner分析日志文件（后面会介绍这个工具）找出错误的原因错误操作的确切时间。3.恢复数据文件：先备份当前数据库文件，然后用上一次备份覆盖现有数据文件。注意：现有的控制文件不会被覆盖。4、基于时间点恢复，启动数据库到组装状态：这样数据库恢复到2015年10月20日9:58:00，然后使用业务数据补充期间的数据这一时期。3.使用dbms_logmnr包从日志文件中恢复。该软件包由Oracle提供。它可以与dbms_logmnr_d包结合使用，轻松分析联机日志文件和存档日志文件，并从这些日志文件中提取对数据库的所有更改。在使用这个包之前，需要做一些设置和修改：1、打开initorcl.ora，修改初始化参数utl_file_dir，设置dbms_logmnr_d包要使用的数据字典文件所在的目录。然后重启数据库使参数生效。2、以sys用户连接数据库，执行dbmslmd.sql脚本重建dbms_logmnr_d包。应用Logminer分析重做日志文件的操作主要包括以下步骤：使用dbms_logmnr_d中构建的存储过程创建外部数据字典文件；使用dbms_logmnr中的add_logfile存储过程添加需要分析的日志文件；使用dbms_logmnr中的存储过程start_logmnr启动Analysis；查询dbms_logmnr相关的几个视图，获取日志文件内容；使用dbms_logmnr中的存储过程end_logmnr结束分析。▲下面详细描述过程1）使用dbms_logmnr_d中的存储过程build创建一个外部数据字典文件：2）使用dbms_logmnr中的存储过程add_logfile将待分析的日志文件添加到待分析文件列表中:如果不是运行在archivemode，那么redolog文件可能会因为redolog文件的循环使用而被覆盖，无法得到你要找的recoveryentry。如果是运行在归档模式下，可以通过查看$ORACLE_HOME\admin\orcl\下的alert_orcl.log中的日志文件归档时间和错误操作时间来确定将哪些归档日志文件添加到待分析文件列表中bdump目录。注意：执行上述过程时，logfilename参数需要写日志文件的完整路径，否则会报错。重复上述操作，直到所有需要分析的文件都添加到列表中。这将开始分析。3）使用dbms_logmnr中的存储过程start_logmnr开始分析；这样，通过下面的查询就可以得到日志文件的内容了。4）查询dbms_logmnr相关的几个视图，得到日志文件内容；这样你就可以找出你需要恢复的语句。注意：v$logmnr_contents只对执行dbms_logmnr.start_logmnr的session有效。如果通过其他会话或使用dbms_logmnr.end_logmnr终止分析，将无法访问v$logmnr_contents的数据。如果想让其他session获取这些数据，可以再创建一张表，如：createtableundo_sqlasselect*fromv$logmnr_contents。然后授权undo_sql，其他用户就可以访问v$logmnr_contents的数据了。5）使用dbms_logmnr中的存储过程end_logmnr结束分析。使用完成后，使用以下命令结束分析活动：execdbms_logmnr.end_logmnr;从而释放分配给logminer的资源（内存和数据结构）。从上面的过程可以看出，如果更新的数据量比较大，但是日志文件比较小，可能会导致日志文件的切换。如果日志文件没有被及时挖掘（没有运行在归档模式下），那么数据可能会因为日志文件的回收而无法恢复。如果以归档模式运行，由于要分析的日志文件数量众多，也可能需要很长时间。4、使用闪回新特性恢复数据Oracle9i开始提供闪回查询（FlashbackQuery）功能，为意外删除或更新并已提交提供简单快速的恢复方法；之前Oracle提供了FlashbackQuery，这种情况下只能通过备份进行时间点恢复或者使用logmnr挖掘日志来恢复，这无疑比flashbackquery更麻烦和耗时。使用闪回查询功能的先决条件：1.数据库必须处于AutomaticUndoManagement状态。2.***闪回查询的时间段由UNDO_RETENTION初始化参数指定（单位为秒），参数值可以通过ALTERSYSTEMSETUNDO_RETENTION=
