根据oracle数据库的特点和提供的工具，主要方法有以下几种方法：
创新互联服务项目包括杏花岭网站建设、杏花岭网站制作、杏花岭网页制作以及杏花岭网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，杏花岭网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到杏花岭省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
利用逻辑备份使用import工具丢失数据的表
利用物理备份来通过还原数据文件并进行不完全恢复
利用dbms_logmnr包从redo log文件中恢复
利用flashback特性恢复数据
前提
为了方便使用方法的介绍，上述恢复方法都将基于以下场景进行：系统管理员在前一天晚上11点用export对数据库做了全库逻辑备份，然后对所有数据文件进行了热备份。第二天上午10点，系统管理员在修改表TFUNDASSET的数据时，由于修改语句的条件写错了，导致一批记录(几千条)的ztm字段被修改成了错误的值，而且已经提交。这个表是资产表，相对而言数据变化不频繁。
一、利用逻辑备份使用import工具恢复丢失的数据
export/import是oracle提供的用于对数据库进行逻辑备份的工具。该工具适用于备份那些数据量不大、业务量不多的数据库系统。因为如果在前一天晚上11点用export做了逻辑备份，那么当今天上午10点数据库意外崩溃时，从备份起到数据库崩溃的这段时间里的数据修改操作(包括DDL和DML)都会丢失。如果丢失数据内的表上的数据是相对比较稳定，也就是说该表上基本没有DML操作，例如标准代码表、分区表里的历史数据，那么采用import来导入该表可以比较完整的恢复数据。如果该表是经常变化的业务表，那么这些丢失的数据只能根据业务情况从纸质记录恢复，或者其他途径恢复。
▲示例如下：这个表是一个资产表。相对来说，今天系统运行中修改的数据较少，丢失的数据量可以承受或者可以从别的途径恢复。那就可以用import来恢复。
方法一：
1、把这个表的数据备份到另一个表：
8bef9890242e5d20d09563896cef1471.png
2、删除该表的记录:
625dfa5d5986ca5c37dd5017953407cb.png
3、执行下面的命令：
3754d50cc473bd44236d927f00196d24.png
这个命令中在关键字tables中指定需要导入的表名字，ignore=y表示忽略表已经存在的错误。
4、导入结束后，检查表中的记录，并用适当的方法恢复当天的修改。
方法二：
1、 把需要恢复的表导入到另一个用户下面：
33806d1216df5ae9c45890d3d45930ee.png
2、检查数据以后，把原表记录删除：
fe23a8a4602702e951e5ab48a7460e3b.png
3、然后从另一用户表中插入回去：
729976810ef459046df40b791a6ca773.png
4、 数据量比较大时可以采用如下方法：
e377d10ff07132f160185cb1ba119cfc.png
二、利用物理备份来通过还原数据文件并进行不完全恢复
如果数据库运行在归档模式下，那么可以通过使用以前的数据文件备份进行还原，然后利用归档日志进行前滚，直到回滚到错误操作的时间点前，然后重置日志文件打开数据库。
可以通过下列方法确认是否是运行在归档模式：
c8406e42aef7ccc8ef232cfdd535e825.png
如果是如上所示，那么就是运行在归档模式了。
▲假定在前一天晚上11点做了全库物理备份，那么可以考虑如下恢复：
1、关闭数据库：
由于数据库的不完全恢复必须在一个关闭的数据库上实施，利用一个旧的数据库的备份还原，然后用日志根据需要逐步前滚，而不能还原一个新的备份，再回退到某个时间点。
通知各客户端数据库将关闭，然后发出：
401f68e89cbfa03388f5913bf5f1ecfd.png
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
2、确定错误操作的时间：
可以根据操作员的估计来确定不完全恢复需要前滚停止的时间，也可以利用LogMiner来分析日志文件(这个工具将在后面介绍)，找出错误操作的准确时间。
3、还原数据文件：
先对当前的数据库文件进行备份，然后再用以前的最近一次备份覆盖现有数据文件。注意：不覆盖现有的控制文件。
4、基于时间点恢复，启动数据库到装配状态：
8802043c250eb2a060285be160f48c36.png
这样数据库就恢复到了2015年10月20日的9点58分零秒。
然后再利用业务资料补充这段时间内的数据。
三、利用dbms_logmnr包从log文件中恢复
这个包是由Oracle提供，与dbms_logmnr_d包配合使用可以方便地分析联机日志文件和归档日志文件，从这些日志文件中提取出所有对数据库的更改操作。
在使用这个包之前，需要先做一些设置和修改：
1、打开initorcl.ora，修改初始化参数utl_file_dir，设置dbms_logmnr_d包将要使用的数据字典文件的放置目录。
eb6dad504d6f5841641cbd02c5f6dee1.png
然后重启数据库使参数生效。
2、以sys用户连接到数据库执行dbmslmd.sql脚本重建dbms_logmnr_d这个包。
应用Logminer分析重做日志文件的操作主要有以下步骤：
● 使用dbms_logmnr_d里的存储过程build创建一个外部数据字典文件；
● 使用dbms_logmnr里的存储过程add_logfile添加要分析的日志文件；
● 使用dbms_logmnr里的存储过程start_logmnr启动分析；
● 查询与dbms_logmnr相关的几个视图来获取日志文件内容；
● 使用dbms_logmnr里的存储过程end_logmnr结束分析。
▲下面详细讲述使用的过程
1、使用dbms_logmnr_d里的存储过程build创建一个外部数据字典文件：
a0975e25f5049f1ffdfdd49ad7ae943d.png
2、使用dbms_logmnr里的存储过程add_logfile添加要分析的日志文件到待分析文件列表：
d16ea343204a3a15b29bc6b94985d48d.png
如果没有运行在归档模式，那么由于重做日志文件的循环使用可能导致日志文件被覆盖而无法获取到所要寻找的恢复条目。如果运行在归档模式，则可以通过查看$ORACLE_HOMEadminorclbdump目录下的alert_orcl.log里日志文件归档的时间和错误操作的时间来确定加入哪些归档日志文件到待分析的文件列表中去。
eff89b61175131d3edda456d8d9bc18e.png
注意：执行以上过程时logfilename参数需要写日志文件的全路径，否则会报错。重复以上操作直到把所有需要分析的文件都加到列表中去。这样就可以启动进行分析。
3、使用dbms_logmnr里的存储过程start_logmnr启动分析；
3630359ea5afa57b5ea51c89da5b8c41.png
这样就可以通过下面的查询来获取日志文件的内容了。
4、查询与dbms_logmnr相关的几个视图来获取日志文件内容；
3f8098efdbe50d4b5b4a5311eab6b5d0.png
这样就可以找出要恢复所需的语句。注意：v$logmnr_contents只对执行dbms_logmnr.start_logmnr的会话有效，如果通过其他会话或者使用dbms_logmnr.end_logmnr终止了分析，都将不能访问v$logmnr_contents的数据。如果要使其他会话也能获取到这些数据，可以通过另外建表来实现，如：
create table undo_sql as select * from v$logmnr_contents。
再对undo_sql进行授权，其他用户就可以访问v$logmnr_contents的数据了。
5、使用dbms_logmnr里的存储过程end_logmnr结束分析。
使用完成以后用下面的命令来结束分析活动：exec dbms_logmnr.end_logmnr;
这样就释放了分配给logminer的资源(内存和数据结构)。
从上面的过程可知，如果是更新的数据量比较大，而日志文件比较小，就可能会导致日志文件的切换。如果没有及时去挖掘日志文件(没有运行在归档模式)，那么可能会由于日志文件的循环使用而导致数据不可恢复。如果运行在归档模式，也可能由于需要分析的日志文件比较多而时间较长。
四、利用flashback新特性恢复数据
Oracle9i 开始提供了闪回查询(Flashback Query)功能，对于误删除或者误更新并且已经commit了的情况提供了简便快捷的恢复方法；而在Oracle 提供闪回查询之前，碰到这种情况只能通过备份来进行基于时间点的恢复或者使用logmnr挖掘日志来恢复，无疑这比闪回查询要麻烦而且费时。
使用这个Flashback Query特性的前提条件：
1. 数据库必须处于Automatic Undo Management 状态。
9d9facd0a8d3e8675284d38f601525d1.png
2. 最大可以闪回查询的时间段由UNDO_RETENTION 初始化参数(单位为秒)指定
b7a419e2f47bd4d31005ca2d9b4a7c58.png
可以通过ALTER SYSTEM SET UNDO_RETENTION = ;来动态修改参数值。
▲如何使用Flashback Query来恢复数据呢？
1. 通过SQL
28b1053a806762ec87261e80f0e8751f.png
使用SELECT 语句的AS OF 来进行闪回查询，语法如下：
使用AS OF 关键字来对表，视图或者物化视图进行Flashback Query，如果指定了SCN，那么expr 部分必须是一个数字，如果指定了TIMESTAMP，那么expr 必须是一个timestamp类型的值。查询结果将返回在指定的SCN 或者时间点上的数据。
下面我们使用scott 方案来作一个实验。
24547dbf2f8f3515319435d98acc0f10.png
如果想在update 的子查询部分使用AS OF，那么该查询只能返回一条记录，否则将会报错。
可以通过添加一个临时表作为中转，然后再作更新，如下：
5605ae591ab357c7148787937df03e17.png
2．通过DBMS_FLASHBACK包来恢复
DBMS_FLASHBACK 包提供了以下几个函数：
ENABLE_AT_TIME：设置当前SESSION 的闪回查询时间
ENABLE_AT_SYSTEM_CHANGE_NUMBER：设置当前SESSION 的闪回查询SCN
GET_SYSTEM_CHANGE_NUMBER：取得当前数据库的SCN
DISABLE：关闭当前SESSION 的闪回查询
当将一个SESSION 设置为闪回查询模式之后，后续的查询都会基于那个时间点或者SCN 的数据库状态，如果SESSION 结束，那么即使没有明确指定DISABLE，闪回查询也会自动失效。
当SESSION 运行在闪回查询状态时，不允许进行任何DML 和DDL 操作。如果要用DML操作来进行数据恢复就必须使用PL/SQL 游标。
▲示例：
fbaf8acfe357d8f21039d588c8b658df.png
通过上面的例子可以看出，只要这个修改的时间不早于sysdate- (UNDO_RETENTION指定的秒数),就可通过这种方式来恢复数据。
e93c4d7b11cf4e7c8ed9a0d27c79ea80.png
对于问题中的批量数据，可以写个过程来完成获取到更改前的数据：
然后再用这个临时表里的数据来更新TFUNDASSET就可以了。
五、总结
比较以上几种恢复数据的方法的使用过程，我们可以看出：
● exp/imp只适合于数据变化不大的表的数据丢失的情况，即使用这种方法处理后也需要从业务办理资料中修正数据，否则导致数据丢失；
● 采用基于时间点的不完全恢复可以恢复丢失的数据，但是需要关关闭数据库，减少系统可用时间，而且也会丢失恢复时间点以后的数据；
● 使用LogMiner可以较好的恢复数据，但是要求数据库尽可能运行在归档模式，否则也可能导致数据丢失。好处是不用关闭系统，能够从日志文件中得到所有的数据。
● 使用Flashback最方便和简洁，可以直接得到修改前的数据，但是需要依赖系统设置，并且需要占用大量的回滚表空间。
因此选择什么样的方法来恢复数据，取决于你的系统环境和具体情况，不能生搬硬套。采用正确的方法才能最大程度的减少数据的丢失。
当然，最好是不需要用到这些恢复的办法。前提是，你必须做好以下的工作：
1、 为不同环境创建不同的数据库用户、不同密码(如果不能用户不同，一定要密码不同)；
2、 将owner和应用用户分开，并做适度授权；
3、 在做DML前，先用同样的条件做查询，看根据结果集是否符合预期。
主要软件版本: 4.4 主要软件修正版本: 4.4 次要软件: N/A 解答:MAX数据库崩溃非常罕见，但是当突然断电或者死机而导致系统非正常关机、重启时可能会导致这一问题。数据库崩溃可能出现的一个现象就是当点击MAX中任一文件夹旁边的扩展按钮“＋”时，文件夹不但不，“＋”还消失了。如果这一现象是在安装了新版本的MAX之后才产生的，您需要确认一下安装之后是否重启了PC。 MAX会备份数据库文件，这可以被用于恢复数据库崩溃。具体步骤如下：以管理员身份或者有管理员权限的用户账号登录（如果安装了F-Secure之类的固件，请确保其在下面的过程中保持关闭！）：退出所有的NI应用程序。
昨天 一个朋友公司的数据库崩溃
这再次印证了我反复提到的一个命题 数据库也需要休息
每逢节假日 数据库也经常会自我选择放假
以前我说 年终难终 进入数据库事故多发期 一年一度今又是 记得另外一个圣诞节 我还和Biti一起在北京的时候 同样遇到一个上海的朋友数据库崩溃 我们远程指导这位朋友恢复了数据
这次的事情是这样的
首先主机宕机 磁盘出错
看到以下这类错误 一般你的数据都很危险了
Dec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit= Dec : : kernel: attempt to access beyond end of deviceDec : : kernel: sda : rw= want= limit=
数据文件大量损坏
当然这次也不例外 大量文件损坏 dbv大量如下错误
[oracle@stat datafile]$ dbv file=o _mf_system_ mn _ dbf blocksize=
DBVERIFY: Release Production on Thu Dec : :
Copyright (c) Oracle All rights reserved
DBVERIFY Verification starting : FILE = o _mf_system_ mn _ dbfPage is influx most likely media corruptCorrupt block relative dba: x (file block )Fractured block found during dbv: Data in bad block:type: format: rdba: x last change scn: x f e seq: x flg: x spare : x spare : x spare : x consistency value in tail: xbc check value in block header: xc cbputed block checksum: xb
Page is influx most likely media corruptCorrupt block relative dba: x e (file block )Fractured block found during dbv: Data in bad block:type: format: rdba: x e last change scn: x b seq: x flg: x spare : x spare : x spare : x consistency value in tail: x c check value in block header: x d fputed block checksum: x dc
控制文件损坏
启动数据库出现如下错误
Wed Dec : : ALTER DATABASE MOUNed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [kccpb_sanity_check_ ] [ ] [ ] [ x ] [] [] [] []Wed Dec : : ORA signalled during: ALTER DATABASE MOUNT Wed Dec : : Starting ORACLE instance (normal)Wed Dec : : Corrupt block found during reading backup piece file=/opt/oracle/product/db g/dbs/snapcf_stat f corr_type=
经过反复确认 这个环境Over了
不完全的备份
以前的备份机制使得我可以从远程主机找到一系列备份集 但是没有控制文件
通过备份集 dbms_backup_restore等手段 首先恢复出来数据文件 然后尝试启动数据库
强制打开
通过强制resetlogs手段打开数据库 出现ORA 错误
Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [] [] [] [] [] []Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : bootstrap process failureORA : bootstrap process failureORA : internal error code arguments: [ ] [ ] [] [] [] [] [] []
通过BBED解决ORA 错误
这个没说的 只能通过BBED搞定了 修复有问题的数据块 再次尝试打开数据库
遇到ORA 错误
这个错误就好解决了 通过我网站上的示例就可以解决
Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : ORACLE instance terminated Disconnection forcedORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : ORACLE instance terminated Disconnection forcedORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []Wed Dec : : Errors in file /opt/oracle/admin/stat/udump/stat_ora_ trc:ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []ORA : ORACLE instance terminated Disconnection forcedORA : internal error code arguments: [ ] [ ] [ ] [ ] [ ] [ ] [] []
解决ORA 号错误
接下来继续出现ORA 号错误 这个也好解决 搞定UNDO表空间就Ok了
Wed Dec : : Errors in file /opt/oracle/admin/stat/bdump/stat_j _ trc:ORA : internal error code arguments: [ ] [] [] [] [] [] [] []
解决一些其他小问题
此处省略 字 终于搞定了用户数据库！
lishixinzhi/Article/program/Oracle/201311/17213
Oracle重做日志
Oracle的重做日志文件(Online redo logfile)循环记录了数据库所有的事务 它的大小 个数和存储位置对数据库性能和恢复有重要影响 它一般由大小相同的几组文件构成 我们可以查看数据库视图v$logfile知道redo logfile的个数和存储位置 对每一个Oracle数据库都要求至少具有两个联机重做日志
每一次新的事务提交时 Oracle将该事务写入日志文件 但并非此时也将修改的数据块写回原数据文件 由于内存读写和磁盘I/O存在几个数量级的效率差别 Oracle通过减少数据文件的物理I/O读写来大大提高数据库的性能 同时 又通过优先写日志文件来保证数据的正确性和一致性 基于这种机制 重做日志文件在数据库的实例恢复和介质恢复时至关重要 是oracle数据库最重要的物理文件之一
如果数据库在启动时检测到重做日志丢失 数据库将无法启动 如果数据库在运行时切换日志文件组 检测到下一组或者全部的重做日志丢失 数据库将会崩溃 由于磁盘介质损坏或者人为的误删除文件 造成严重后果的事件近期时有发生 本文列举了重做日志丢失的数据库恢复 但如果按照冗余原则合理分布日志文件组的成员 如果工程师了解日志文件的基本原理和使用原则 就完全可以避免出现下列问题
恢复方法
故障现象
SQL startup mount
Oracle Instance Started
Database mounted
ORA : open failed for members of log group of thread
ORA : online log thread : /ORACLE/ORADATA/H /REDO LOG
ORA : unable to open file
OSD : unable to open file
O/S Error: (OS ) The system cannot find the file specified
恢复注意事项
以下所列举的恢复方法 都属于不完全恢复或者强制恢复 会丢失当前重做日志中的事务数据 一旦操作不当 将带来数据丢失等严重后果 请遵循以下几个恢复原则
请勿在生产系统上试用
如果生产系统出现重做日志文件丢失的故障 请勿自行操作破坏现场 应该立刻联系Oracle工程师
恢复成功之后 需要马上做一次数据库的全备份
建议重做日志文件一定要实现镜象在不同的磁盘上 避免这种情况的发生
恢复方法
首先检查重做日志文件状态 看看报错的日志文件的状态是否为Current
SQL select * from v$log;
SQL select * from v$logfile;
如果重做日志文件状态为Inactive 我们可以直接清除该日志文件的内容
SQL alter database clear logfile /ORACLE/ORADATA/H /REDO LOG ;
如果重做日志文件状态为Current 恢复工作较为复杂 有以下四种情况
）通过下面步骤 数据库顺利打开
SQL recover database until cancel;
Type Cancel when prompted
SQLalter database open resetlogs;
）第一种情况的 recover database until cancel 操作遇到ORA ORA ORA 错误 需要整个数据库的物理备份 并根据归档日志恢复到错误时间点 前提是数据库是归档模式
restore old backup
SQL startup mount
SQL recover database until cancel using backup controlfile;
SQL alter database open resetlogs;
）如果数据库是非归档模式 只能恢复整个物理备份 然后直接打开数据库 这种情况将丢失物理备份至故障发生前的全部数据
）如果数据库是非归档模式 且没有物理备份 只能通过特殊的隐含参数 允许数据库不一致的状况下打开数据库 这种恢复方法是没有办法之后的恢复方法 将导致数据库不一致 一般情况下不要采用 如确有需要 请在Oracle的技术人员指导下使用该方法
? 关闭数据库
SQLshutdown immediate
? 在initsid ora中加入如下参数
_allow_resetlogs_corruption=TRUE
? 重新启动数据库 利用until cancel恢复
SQLrecover database until cancel;
Cancel
? 打开数据库
SQLalter database open resetlogs;
? 数据库被打开后 马上执行一个全库导出
关闭数据库 在initsid ora中去掉_all_resetlogs_corrupt参数
lishixinzhi/Article/program/Oracle/201311/16743
Oracle概念问题 假如数据没有提交 但是却被dbwn进程写入了数据文件 会怎么样呢？
案例分析
首先说明的是dbwn写脏数据跟mit提交没有关系！
在一个transaction发生的过程中 online redo log首先记录transaction中修改的数据块相关信息 修改的数据块会被缓存在database buffer cache中 由于database buffer cache写满或者checkpoint等等条件触发dbwn进程 会导致这些缓存的数据块写入数据文件 但此时可能该transaction仍然还没有提交 所以在数据文件中 可能会有mited 和 unmited 的数据块 而原有的数据块镜像会存放在undo segment
IXDBA NET社区论坛
然而 dbwn写脏数据时不管这个要写的transaction是否提交
也没有必要去管
这样就发生了所谓的已经提交的数据 但是还没有写入数据文件的现象
还有一种情况 数据没有提交 但是已经被写入数据文件 此时发生回退 撤销没有提交的数据
那么 引发Oracle前滚与回退的根本原因就是什么呢？
根本原因是mit后写redo buffer和触发lgwr写 redo buffer的区别
事务在执行完毕后 随即会被写入redo buffer和undo中 同时在redo buffer和undo中对该事务都有一个是否提交的标记 两者的默认状态都是active的 即没有提交时刻处于激活状态
mit操作执行时刻把此前的所有事务操作全部写入redo log file mit成功后 redo buffer信息全部写入redo file 同时修改两者中的事务提交标识为inactive 表示此前事务已经递交
oracle的前滚和回退根据就是依据事务是否提交而进行的
在触发lgwr进程后 oracle同样把此前的redo buffer信息写入redo file 但是与mit触发写日志不同的是 redo file本身对lgwr写日志操作不记录任何信息标识 lgwr写到那里就是那里 就算此时掉电也无妨 redo file就记录到掉电时刻的信息
lgwr是一个Oracle后台执行的进程 具体的日志写操作都有oracle去控制 这对于oracle来说是透明的 因此不用在redo file中写入任何标记信息 这也是正常的
mit操作是唯一一个可以前台操作与oracle后台通信的指令 因此当加入这个操作以后 oracle本身必须要了解各个事务的读写状况 那么怎么了解整个状况 在redo以及undo中加入是否递交的标识 对于已经提交的操作 但是还没有写入数据文件 那么就要前滚 相反 对于没有提交 执行回退！
于是 Oracle崩溃恢复步骤如下
首先rolling forward 前滚 由于oracle failure sga中的内存信息丢失了 但是online redo log中还是存储了transaction信息 包括mited or unmited data 可能这些修改信息并没有被oracle正确的来处理 包含两种情况 已经提交的还没有写入数据文件 或者没有提交的却被写入了数据文件 针对已经提交的还没有写入数据文件就要发生前滚 在前滚过程中 *** on会根据online redo log中的记录来完成对datafile的修改 保证已经提交的数据已经写入数据文件
接下来 前滚结束后 数据库正常open 此时用户可以正常连接 可以访问已经recover的mited data 但是对于那些属于unrecoverable transaction的unmited data 会被oracle 加锁 是不可以访问的
lishixinzhi/Article/program/Oracle/201311/16619
oracle数据库恢复,主要包括(1)系统崩溃只剩下数据文件的情况下的恢复,甚至没有system表空间而只有数据表空间的情况下的恢复.只要提供数据文件就可恢复.(2)undosystem表空间损坏数据恢复.(3)非归档或者归档模式下误delete数据的恢复、误删除表空间的恢复、droptruncate表的恢复.(4)数据库中有大量CLOBBLOB对象数据恢复等情况以及各种ora-错误的修复.(5)DMP文件损坏导致文件不能导入数据库的数据恢复(6)oracle数据库中数据文件出现坏块情况下的恢复.(7)oracle数据库无数据文件但有日志的情况下的恢复.(8)UNIX、WINDOWS下ORACLE数据文件被误删除情况下的数据库恢复.(9)Oracle10G、Oracle11G的ASM损坏的数据库恢复.(10)Oracle10G、Oracle11GBIFGILETABLESPACE大文件表空间损坏数据恢复(11)Oracle9i、Oracle10G、Oracle11G压缩表压缩表空间损坏数据恢复(12)Oracle10GOracle11GExpdp导出Impdp导入DMP文件错误数据恢复恢复成功率高达90%以上,在数据恢复领域处于国内领先的地位。具体案例见广州拓飞官方网站
