对于没有有效物理或逻辑备份的场景，当Oracle中发生delete误操作时 一般会优先考虑使用flashback闪回或logminer日志挖掘等技术来恢复Oracle表中的数据行记录，但很多时候flashback或logminer都无法力挽狂澜。

 

对于delete操作而言，其对于oracle底层数据块block中的row piece记录一般仅仅是修改其row flag标记为已删除标记，容许后续INSERT的记录覆盖这些被标记为delete的数据，也容许破坏这些delete掉的数据的结构。 换句话说如果delete后没有对表做什么操作的话，直接读取block中的这些被标记为deleted的记录还是有可能读取到完整数据的。

总而言之，是否能恢复这部分delete掉的数据，完全取决于磁盘上oracle block中这部分删除的数据行是否有被最终清理掉。

在被清理掉之前ORACLE PRM-DUL工具都可以尝试把这部分数据恢复出来， 具体步骤与普通的数据字典模式差别很小。

启动PRM-DUL 点击恢复向导  字典模式

 

 

 

 

 

 

加入所有oracle数据文件，不需要加入临时文件TEMPFILE、UNDO数据文件、控制文件、日志文件

 

点击load 按钮，PRM会自动加载数据字典 即bootstrap动作

 

 

至此 PRM左侧将出现 树形的对象树，选择你需要恢复的用户下的对应数据表, 右击对象后选择 unload deleted data

 

 

 

PRM-DUL 完成对已删除数据的恢复操作后会将 数据写出到  上图中 File path的位置， 示例的数据恢复情况如下：

 

 

 

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

本文地址：https://www.askmac.cn/?p=16600

 

为满足重大故障的紧急救援需求，SSC提供了如下的专业化、制度化的救援流程：

 

 

即一旦客户IT系统出现1级或升级2级严重问题，客户DBA可第一时间拨打Oracle公司专门为SSC客户提供的7*24小时的值班电话，当SSC值班工程师接到救援电话之后，会马上听取客户的情况介绍，并判断问题的严重程度和影响范围。根据客户需求和问题情况，SSC可确定是否可以通过电话或VPN登录方式，进行远程解决 。同时，客户也可拨通服务实施经理（SDM）电话。SDM可与SSC工程师沟通故障情况，并根据客户需求确定是否需要安排工程师去现场。如果的确问题非常严重、难以远程解决， SDM会果断决定派出客户当地城市或最近城市的工程师，同时深圳的SSC团队也会考虑派出工程师赶赴现场。当工程师到达客户现场后，会立即与客户运维团队、应用开发商、 硬件等其它厂商进行会商，并根据问题症状分析出问题原因所在，最终提供问题解决方案并加以实施。在故障彻底解决并验证之后，将提交故障处理分析报告。

以下就是Oracle最近在某移动公司出现重大故障时的响应速度：

 

 

时间点	操作内容
… …	… …
10月30日 21:58	在节点2出现ORA-600 [qertbFetchByRowID]告警，紧接着节点1也出现ORA-600 [kclchkblk_3]告警
10月30日 22:00	业务方面反映20多张表不能插入
10月30日 23:04	重启数据库后，数据库还是出现ORA-600 [kdsgrp1]告警
10月31日 2:10	SSC值班接到保障电话，开始对问题进行分析
10月31日 3:00	SSC工程师远程登陆数据库，对有问题的表的索引进行分析及重建，发现相关索引在重启后恢复正常。
10月31日 6:00	发现大部分表恢复正常访问，业务基本恢复，但后台持续有报错。
10月31日 6:06	容灾库尝试启动但报错ora-01172无法启动
10月31日 6：45	华东区工程师从杭州出发赶往现场支持
10月31日 7：00	SSC工程师从深圳出发赶往现场支持，
10月31日20:00	现场多次checkpoint后，断开同步后，容灾库正常启动成功
… …	… …

可见当该移动客户在10月31日21：58分发现Oracle出现故障之后，刚开始通过自身DBA和第三方运维公司技术人员进行自救。但23：04采取重启数据库之后，数据库还是出现相关错误，不得已在凌晨2：10拨打了SSC值班电话， SSC一方面通过电话进行问题分析，另一方面在解决了远程登陆问题之后，于3：00登陆至客户系统进行分析，并采取了针对性的救援措施，缓解了部分问题。但仍然没有彻底解决问题，于是，Oracle果断决定派出工程师，本地工程师6：45从杭州开始赶头班高铁赶赴现场，深圳的SSC工程师赶7：00的头个航班飞赴现场。这就是SSC服务包为客户提供的最高级别响应速度和服务级别了！

而且，就是为了解决该客户的此次重大故障，尽管最终原因是硬件厂商的磁盘镜像技术导致的数据损坏， Oracle其实是受害者，但Oracle不惜血本，从本地到远程，从国内到国外，Oracle投入了120多人天，而且还没有包括管理层、销售层面的大量投入。最终不仅是Oracle公司发现了问题根源，并有效解决了该问题，以及延伸的其它问题，而且在未来如何根治该类问题，从IT系统高可用性架构、容灾建设等方面给予了客户更广泛和深远的建议。

这就是SSC紧急救援和主动服务相结合给客户带来的价值和回报！

• A类和B类的紧急故障救援

SSC服务包是以系统套数进行计价的，但服务的系统又区分为A类和B类。故障紧急救援方面，针对A类系统的服务项目如下：

• 1级SR和升级2级SR故障7×24紧急救援
• 1级SR恢复阶段的7*24跟进与分析
• 1级SR和升级2级SR的问题的根源分析跟进（5*8跟踪）
• 问题的管理与跟踪（报到SSC平台的1级和升级2级问题）

同时，故障处理由Oracle资深专职组工程师负责，针对1级故障（SR1）一天两次的主动通知，2级故障（SR2）每周汇报。根据oracle全球支持策略，1级故障为7*24跟踪，1级以下故障为5*8跟踪。 1级故障当系统恢复正常后， 降级为2级故障进行根本原因定位分析。

针对B类系统的服务则是：仅对1级SR故障进行系统救援支持，系统恢复服务后，工程师离场并不再提供任何问题的持续跟进和原因分析。

总之，A类系统的故障救援服务更为全面，既救命又治病，而B类系统则只救命，并不负责根治所有疾病。当然，A类系统的服务价格更昂贵。

如果客户系统很多，又都需要紧急故障救援服务，如何在价格和服务价格之间进行平衡？建议就是将需要保障的系统都纳入SSC服务范畴，但在A类和B类之间进行平衡，毕竟B类服务价格相对A类便宜很多。