PRM-DUL Tool – Your Oracle Database Recovery Expert Here

2016/08/23 by admin Leave a Comment

PRM-DUL Oracle Database Recovery Tool (PRM-DUL) is one advanced tool developed for Oracle data recovery.

From release 1.0 to now, more functions and enhancements have been built into the new version. And continuous bug fixes and logical improvements support it to be now more stable in various enterprise environment.

Many cases have proved that PRM-DUL Oracle Database Recovery Tool can work well on multiple OS platforms (AIX/HPUX/SOLARIS/Linux/Windows). The current version now support Oracle 9i/10g/11g/12c Oracle Databases Data Rescue Operations.
It is a Java based, free installation software. You can start it directly after download and unzip the package. (On Windows, click the executable file prm.bat. On Linux/Unix, the start file is prm.sh)
** We advise users to use Java 1.6 or higher version before trying PRM-DUL 4.0.
Java official version can support most of PRM-DUL functions except raw device operations. If you are using this tool for raw device data recovery, please install Java OpenJDK instead.
PRM-DUL GUI interface can help user for easy use. It is not necessary for users to learn extra sets of commands or try to understand Oracle data file layout structures. Through PRM-DUL Recovery Wizard, we can easily rescue the database data and “save my life” J.
PRM-DUL supports single data file scan and data extraction, it also supports Oracle ASM storage data recovery.

The rescued data can be exported in sql loader data file format. And also we can use PRM-DUL Data Bridge function to export data and insert into one another new database directly, that means data can be rescued and recovered without staging.

————————-

Version 4.0 Enhancements：

Support data recovery for table DELETE wrong operations.
Great improvements on exporting performance for LOB data bridge in dictionary mode.
Add support for LOB data bridge in non-dictionary mode.
Add support for re-use dictionary mode/non-dictionary mode scanning data info.
Add DDL export support at schema level

————————-

PRM-DUL Oracle Database Recovery Tool – Major functions：

Can do data scanning and analyzing on database files, no matter Oracle Database is running or not.
Support ASM, PRM-DUL can read ASM storage disks directly, find the data files and then do the data scanning and analyzing.
Support raw devices data files reading.
Support LOB (CLOB, NCLOB and BLOB) column data recovery, it also supports the case when different LOB columns have different chunk size in one same table.
Support Oracle database recovery on multiple Big Endian or Little Endian operating systems (AIX/HPUX/SOLARIS/Linux/Windows).
Support partition, sub-partition data recovery
Support various table data recovery, which also includes HEAP tables and CLUSTER tables.
Support truncated table data recovery.
Support dropped table data recovery.
Support Non-dictionary mode data recovery when SYSTEM table space is missing or data dictionary is broken. Provide part of block data to assist user to determine the data type for recovery.
Support BigFile table space data recovery.
Support data files with different block sizes in one same database.
Support CREATE table SQL file and sqlldr control file auto-generating when rescued data is exported into flat file.

————————-

In the growing enterprise IT systems, data capacity is expanding in geometric progression. Even if DBAs are aware of the importance of backup, they will still suffer from problems such as lack of backup storage space, backup failures or unavailable, physical storage disaster damage, and so on. Therefore, it’s necessary for DBAs to familiar with a physical data recovery tool and understand how to use it.
If your Oracle database downs due to an unexpected failure, the physical storage is damaged and cannot be restarted, and you are stuck in the backup is too old to be used. Then you can consider trying PRM-DUL for emergency rescue processing.

————————-
There are many types of errors to show Oracle Database’s disaster damage or block corruption:
Such as block corruption/bad block, index corruption/ bad block, row corruption/ bad block, UNDO corruption/bad block, control file corruption, consistent read problem, data dictionary corruption, data file/RDBA/BL problem etc. If you meet ORA-1578 / ORA-8103 / ORA-1410 / ORA-1499 / ORA-1578 / ORA-81## / ORA-14## / ORA-26040 / ORA-600 …errors but failure to recover it, we advise you to try PRM-DUL as one of your data rescue means.

————————-

PRM-DUL Oracle database recovery tool has two editions (for Community and Enterprise):

Community Edition – Oracle database users can free download the latest version at any time from parnassusdata.com. Without the purchase of License, the software is free for use as a community version, the community version allows each table up to 10,000 lines of data rescue export, so users can use the software for free on some small databases.
Enterprise Edition – If the table row number required to be recovered is more than 10,000 and you’ve tried PRM-DUL and confirm it can fix your problem. Then you can visit the official website and consider to purchase the Enterprise License for this tool. After the registration for the software by using the license you’ve got. Your software can be upgraded from the community edition to the enterprise one. The enterprise edition has no line number limit, and all other functions and enhancements will be open to you.

————————-

If you have more questions about using this tool or you need more help on it, don’t hesitate to visit the official website at http://www.parnassusdata.com/. Call the hotline or email our software service for additional help.

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Recovering a Deleted Oracle Datafile Without a Backup

2016/08/23 by admin Leave a Comment

Recovering a Deleted Oracle Datafile Without a Backup

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle PRM-DUL Undelete Oracle record/rows

2016/03/07 by admin Leave a Comment

Download PRM-DUL http://www.parnassusdata.com/en

On scenarios without valid physical or logical backups, when a mistaken delete occurred in Oracle, it will be given priority to use techniques such as flashback or logminer to recover the data rows in Oracle tables in general, but in many cases even flashback or logminer could not turn the tide.

For the row piece in the underlying data block of Oracle, delete operation only modify the row flag and mark them as deleted. It allows records of the subsequent INSERT to override these data marked as delete, and also allows to destroy the structure of these data that are deleted. In other words, if no operations has been done on tables after delete, it is possible to read the complete data by directly reading those records that are marked as deleted in blocks.

In a word, whether it can recover the deleted data or not all depends on whether the deleted data rows in oracle block on the disk have been eventually cleared or not.

As soon as it has not been cleared, ORACLE PRM-DUL can attempt to recover the data, and the specific steps has little difference with the ordinary data dictionary mode.

Start up the PRM – DUL, click the restore wizard in dictionary mode

Add all of the Oracle data files, no TEMPFILE, UNDO data files, control files, log files is required.

prm-undelete6

Click the load button, PRM will automatically load the data dictionary, i.e. bootstrap operation

ow on the left of PRM, you will see the object tree, select the corresponding data table under the user that you need to recover, right-click the object and then select unload deleted data.

prm-undelete8

After completing the recovery of the deleted data, PRM-DUL will write the data to the location of File path in the picture above, the Sample data recovery is as follows.

prm-undelete10

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

PRM-DUL Undelete恢复被Delete操作删除的Oracle记录/行 record/rows

2016/02/21 by admin Leave a Comment

对于没有有效物理或逻辑备份的场景，当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的位置，示例的数据恢复情况如下：

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle SSC紧急故障救援流程

2016/02/18 by admin Leave a Comment

作者为:

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类便宜很多。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 防范人为操作失误的最好技术：FLASHBACK

2016/02/18 by admin Leave a Comment

作者为:

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

本文永久地址：https://www.askmac.cn/?p=16586

针对主机故障、网络故障、系统软件故障、存储介质故障、人为操作失误等各类故障，Oracle公司都提供了相应的技术方案。例如RAC、RMAN、Data Guard等，其中防范人为操作失误的最好技术就是10g之后的FLASHBACK技术。

可惜，在本人与国内众多行业的广大客户接触中，发现大部分客户DBA和开发人员都缺乏对FLASHBACK技术的深入、系统的研究和应用。问其原因，得到的回答往往是：“FLASHBACK技术很消耗资源，不敢打开”。其实，客户说的是Flashback Database技术，该技术需要打开Flashback Log，的确消耗一定资源。而实际上，FLASHBACK技术不是一个单一技术，而是一个技术簇：Flashback Database、Flashback Drop、Flashback Table、Flashback Query等，而上述很多技术是缺省就打开，我们可以直接使用的，并不额外消耗资源。

本章就将先从案例开始，然后系统介绍FLASHBACK技术家族，以及在测试、安全审计、容灾，以及与其它数据保护技术结合等方面的应用。

人为错误的防范

当年天塌下来一样的重大事故

本人在《品悟》一书的第一章，曾经描述过某大型银行一个重大事故：在2007年初该行一位工作人员在分析和测试一个性能问题时，错误地将生产环境当成测试环境，一个Delete操作将生产系统中一张核心业务表的大部分数据删除掉，导致业务被迫中断。后来通过传统的Imp工具，从前一天的逻辑备份数据中进行了恢复，同时通过业务人员几乎通宵达旦的的数据补录，才将当天数据全部恢复，确保了第二天业务的正常运行。当年该事故引起了该银行高层的高度重视，Oracle公司各服务部门也投入了大量技术力量。

如今回想起来，该银行不仅需要在操作流程规范和访问环境方面进行深入总结，而且在技术方面更是感慨良多。当年该系统还是9i版本，只能采取上述传统的逻辑恢复和数据补录方式，不仅导致恢复时间长，而且还不能保证数据完全被恢复。如果是10g以上版本，上述故障则可以通过如下类似命令进行恢复了：

/*+ 回退到5分钟之前 */

flashback table <表名> to timestamp(sysdate-1/288);

上述语句不仅简单，而且非常快速，并且能保证数据得到完整恢复。

这就是技术进步！这就是本章要讲解的主题：Flashback。

人为错误是最大单一因素

根据国内外IT行业的统计，在导致系统不可用的因素中，人为错误其实是最大的单一因素，占到40%以上，如下图所示。人为错误概率其实远远高于服务器硬件故障、网络故障、系统软件故障、存储介质故障等。

常见的人工操作失误包括：

错误地删除（Drop）了某张业务表
错误地清除（Truncate）了某张业务表的全部记录
错误地修改（Update）、插入（Insert）、删除（Delete）了某张业务表的记录
错误地运行了批处理程序，例如重复运行了批处理程序，导致业务数据紊乱
… …

如何快速、稳妥地对人工操作失误导致的数据损失进行恢复，是涉及数据库系统数据安全性设计、日常运行维护等方面工作的重要挑战。

传统技术手段

为对人工操作失误导致的数据损失进行恢复，Oracle的传统技术示意图如下：

exp/imp或Data Pump技术

通过Oracle传统的数据卸载（Exp）或10g Data Pump（Expd）技术，定期进行数据逻辑备份。在发生数据误错误时，通过数据装载（Imp）或10g Data Pump（Expd）技术，在表（table）、模式（schema）、数据库（database）等不同级别进行数据恢复。

RMAN不完全恢复技术

如果发生大规模数据误操作，通过RMAN不完全恢复可将数据库恢复到指定的过去某个时间点、SCN号或日志序列号，达到在数据库级进行数据恢复的目的。

表空间按时间点恢复技术（Tablespace Point-in-Time Recovery，TSPITR）

Oracle提供了在表空间级按时间点进行RMAN数据恢复的技术，可使该表空间恢复到与数据库其它表空间不同的时间点。如果在发生较大规模数据损坏时，表空间按时间点恢复技术提供了更灵活的恢复手段。

传统数据恢复技术的缺点如下：

恢复时间长

传统数据恢复技术均存在恢复时间长的问题。例如RMAN不完全恢复技术，需要先将整个RMAN备份集进行restore操作，然后再通过联机日志和归档日志进行不完全的向前恢复（recover）。因此，恢复时间不仅取决于误操作的时间长短，更与整个数据库容量相关（restore时间）。即：

恢复时间 = 恢复误操作时间 + f(数据库容量)

恢复时效性差

传统数据恢复技术基于数据库备份技术，以及日志向前恢复技术。恢复数据的时效性取决于备份频度。例如，如果每天夜间进行exp操作，则最早只能恢复到前天夜间进行exp的时间点，无法恢复到发生错误前的更近时间点，如10分钟之前。

恢复灵活性差

RMAN不完全恢复是基于数据库级的，表空间按时间点恢复技术是基于表空间级的，Exp/Imp虽然可在表、模式、数据库等不同级别进行数据恢复，但恢复的时效性差。总之，传统数据恢复技术灵活性差，例如无法做到记录级恢复。

恢复操作复杂

传统数据恢复技术都比较复杂，无法做到一条命令或一键到位式的快速数据恢复。例如，表空间按时间点恢复技术（Tablespace Point-in-Time Recovery，TSPITR）就涉及RMAN环境配置、Auxiliary事例配置等复杂过程。

快速恢复数据的新技术：Flashback

Oracle 从10g开始提供了更丰富、快捷的数据恢复技术手段，即Flashback闪回技术。与传统的通过Exp/Imp、RMAN、表空间按时间点恢复（Tablespace Point-in-Time Recovery，TSPITR）等技术不同的是，Flashback不需要将整个数据库或大量数据文件从备份集中进行恢复，而是通过从UNDO、Flashback log、Flashback Data Archive，Flashback就可实现对过去数据的恢复。Flashback原理和示意图如下：

Flashback是一个技术簇，包括：

Flashback Database
Flashback Drop
Flashback Table
Flashback Query
DBMS_FLASHBACK包
Flashback Version Query
Flashback Transaction Query
11g的Total-Recall

例如，当由于应用程序错误导致数据被损坏时，通过Flashback技术，可将指定表甚至整个数据库闪回到错误发生之前的状态，从而最大限度地达到保护数据的目的。

相比传统的数据恢复技术，Flashback闪回技术总体上具有如下优点：

Flashback闪回技术更快捷
Flashback可灵活地在数据库、表、记录级进行恢复
Flashback闪回技术不需要复杂的实施步骤，实施命令更为简单
Flashback不仅用于数据恢复，而且可用于安全审计、数据变更历史跟踪分析、应用测试、容灾系统建设等其它方面

14.2数据库级快速恢复

当数据库出现了如下大规模误操作情况下：

大范围错误地修改、删除和插入了业务数据，特别是主要业务数据。
错误地运行了批处理程序，例如错误或重复地运行了批处理程序，导致业务数据大范围紊乱。
错误地删除了用户。

如何进行快速恢复？

Flashback Database技术

Flashback Database技术可在数据库级快速恢复到过去某个时间点、SCN号或日志序列号，提供了类似录音机的回退键（REWIND）功能。以下就是其原理图：

启动Flashback Database技术

Flashback Database技术不是Oracle数据库缺省打开的。欲启动Flashback Database技术，需完成如下配置过程：

/*+ 配置flash recovery area */

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 4G;

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = ‘/oracle/frec_area’;

/*+ 配置retention target参数 */

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=2880;

/*+ 启动Flashback Database */

ALTER DATABASE FLASHBACK ON;

采用Flashback Database技术

当发生上述大规模误操作时，以下是主要恢复流程和语句：

/*+ 查询当前SCN号 */

select current_scn from v$database;

/*+ 查询当前Log Sequence号 */

archive log list;

shutdown immediate;

startup mount;

/*+ 回退到过去某个时间点 */

flashback database to timestamp(to_date(‘2009.10.02 20:03:00′,’YYYY.MM.DD HH24:MI:SS’));

flashback database to timestamp(sysdate – 1/24);

/*+ 回退到过去某个SCN号 */

flashback database to scn 3775124;

/*+ 回退到过去某个Log Sequence号 */

flashback database to sequence=223 thread=1;

alter database open resetlogs;

Flashback Database的监控

通过如下视图可监控Flashback Database的使用情况：

/*+ 是否打开Flashback Database功能？ */

Select flashback_on from v$database;

/*+ 查询Flashback Database总体情况 */

Select * from v$flashback_database_log;

/*+ 每隔一小时，统计分析Flashback使用情况 */

select * from V$FLASHBACK_DATABASE_STAT

上述视图各字段的详细含义请参考Oracle联机文档的《Oracle® Database Reference 11g Release 2 (11.2)》

Flashback Database的内部机制

不解渴的技术控一定想深入了解Flashback Database内部机制，以下就是Flashback Database内部机制示意图。

即Oracle为实现Flashback Database，新设计了Flashback Buffer缓存区，并通过新的后台进程RVWR将变化之前的数据块映像（before images of data blocks）定期写入Flashback Database Log中。

当数据库需要进行Flashback时，Oracle将按时间倒序方向读取Flashback Database Log进行恢复，而传统的Redo Log则是按时间正序方向读取并进行恢复的。

评估分析

同传统RMAN不完全恢复技术相比，Flashback Database技术具有如下显著优点：

恢复时间快

Flashback Database技术是基于10g新的Flashback Log，在进行数据库快速恢复时，不需要象传统RMAN技术一样先进行数据库的restore操作，再进行日志文件的向前恢复（Forward Recovery），从而耗费大量时间，而是直接通过Flashback Log回退到过去某个时间点或SCN号。因此，Flashback Database恢复时间仅取决于误操作的发生时间长短，与整个数据库容量无关。即：

恢复时间 = 恢复误操作时间 + f(数据库容量)

恢复时效性好

在10g中，Flashback Log存储在快速恢复区（Flash Recovery Area）中，只要快速恢复区容量足够大，并通过初始化参数DB_FLASHBACK_RETENTION_TARGET的设置，Flashback Database技术可快速回退到过去指定的时间或SCN号。因此，具有恢复时效性好的特点。

恢复操作简捷

Flashback Database不是数据库的缺省配置，需要进行一定的手工配置过程。但在需要进行数据库快速回退时，基本上通过上述的简单几条命令即可完成。

最佳实践经验

Flashback Database是在数据库级进行整体快速回退，无法针对单独的表和记录进行快速回退。即Flashback Database操作之后，数据库中所有对象均回退到过去某个时间点状态。
快速恢复区（Flash Recovery Area）和初始化参数DB_FLASHBACK_RETENTION_TARGET需要进行合理配置，从而保证在资源消耗和恢复时间长度方面进行综合平衡。
Flashback Database在某些情况下不能进行快速恢复。例如控制文件进行restore或重新创建之后；表空间被删除之后；数据文件被回缩（shrink）之后；Flashback Database不能恢复到resetlogs操作之前。

错误删除表的快速恢复

用户错误地删除（Drop）掉一张表，如何进行快速恢复？

Flashback Drop技术

Flashback Drop技术概述

通过10g新的Flashback Drop技术，可快速恢复被用户误删除（Drop）的表。与传统drop table语句不同的是，从10g开始Oracle的drop table操作并不是立即将该表删除掉，而是进入了Recycle Bin，Recycle Bin位于与原表相同的表空间。尽管DBA_FREE_SPACE视图显示该表的空间被释放了，但实际上该表的空间并没有立即释放。

保存在Recycle Bin被删除的表，其表名和相关对象、限制等名称都将被更名，以免之后创建同名表时引起名称冲突。

通过如下一些视图可显示Recycle Bin中的内容：

/*+ 查询所有用户的Recycle Bin内容 */

Select * from dba_recyclebin;

/*+ 查询当前用户的Recycle Bin内容 */

SELECT original_name, object_name,

type, ts_name, droptime, related, space

FROM user_recyclebin

WHERE can_undrop = ‘YES’;

/*+ 查询当前用户可恢复的Recycle Bin内容 */

Show recyclebin;

快速恢复被删除表

通过如下命令，可快速恢复被删除表：

flashback table <table_name> to before drop [rename to <new_name>];

其中<table_name>可是原来表名，也可是保存在Recycle Bin中系统产生的名称。

当指定原表被多次删除过，即Recycle Bin中有多份同名表时，Oracle采取后进先出（LIFO，Last In First Out）算法，将最新被删除的该表先恢复。如果您需要恢复到更老版本时，可指定<table_name>为系统产生的名称，或者多做几次Flashback table操作，直至您需要的版本。

如果恢复过程中出现重名了，除非使用rename to <new_name>，否则系统回报错。

另外需注意的是，Flashback table操作只将表名恢复成原来的表名，相关的索引、触发器、限制等将使用在Recycle Bin中系统产生的名称。因此，为恢复原来可读性强的名称，建议在Flashback table之前最好先查询Recycle Bin和其它视图，以便进行相应的更名操作。

Oracle如何进行Recycle Bin空间管理？

如上所述，Recycle Bin位于与原表相同的表空间。那么，Oracle如何进行Recycle Bin空间管理呢？一种方式是通过手工执行Purge操作，另一种方式是按如下原则进行自动化管理：

假设新建一张表，Oracle首先从Recycle Bin之外的空闲空间为该表分配空间。
如果空闲空间不够，Oracle通过先入先出（FIFO）策略，将Recycle Bin中的部分表彻底删除，为该新表分配空间。
如果空间还不够，假设该表空间的数据文件是自动扩展的，Oracle则通过扩展数据文件，分配更多空间。

评估分析

同传统恢复技术相比，特别是Exp/Imp技术相比，Flashback Drop技术具有如下显著优点：

恢复时间快

如果使用传统Imp技术进行恢复，需要将该表记录全部重新加载（Insert操作），并且重新分配空间。而Flashback Drop技术是基于Recycle Bin技术，即被删除表的数据依然存储在与该表相同表空间的Recycle Bin区域中，Flashback Drop只是将Recycle Bin区域中被删除表的记录进行恢复，不需要Insert操作，更不需要重新分配空间，因此恢复时间非常快。

恢复时效性好

传统Imp技术只能将该表恢复到最近一次Exp的时间点，将丢失最近一次Exp时间点到错误drop之间的变化数据。而Flashback Drop则是直接恢复到错误drop之前的数据状态，因此恢复的时效性非常好。

恢复操作简捷

如上所见，Flashback Drop基本上通过一条命令即可快速恢复被误删除的表。

最佳实践经验

Flashback Drop是10g数据库的缺省配置。即drop table操作，被删除的表都会进入recycle bin。因此，对于需要一次性正常删除表的操作，可在drop table语句中增加purge选项，例如：

Drop table <table_name> purge;

通常情况下，当表空间的空间不够时，Oracle会自动进行recycle bin的空间释放。但建议DBA能定期通过各种purge命令(purge table, purge tablespace, purge [user_|dba_]recylebin等)进行recycle bin的手工空间释放。
Flashback Drop只针对非SYSTEM表空间的表、存储在Local管理表空间的表，以及没有使用FGA和VPD技术的表。
Flashback Drop不能恢复与被删除表相关的Bitmap-join索引、物化视图日志以及为保持数据完整性的参考限制（Referential integrity constraints）。

表级快速恢复

如果用户错误地进行了各种DML（Insert,Delete,Update等）操作时，如何在表级进行快速恢复？

Flashback Table技术

通过10g/11g的Flashback Table技术，可针对单表或多表快速恢复错误DML操作的数据，以下是主要恢复流程和语句：

/*+ 查询当前SCN号 */

select current_scn from v$database;

alter table employees enable row movement;

alter table departments enable row movement;

/*+ 回退到一个小时之前 */

flashback table employees to timestamp(sysdate-1/24);

/*+ 回退到过去某个SCN号 */

flashback table employees to scn 3775124;

/*+ 同时回退2张表到5分钟之前 */

flashback table employees,departments to timestamp(sysdate-1/288);

Flashback Table在闪回期间，触发器将不会启动，除非在Flashback Table语句中增加了“enable triggers”短语。例如：

/*+ 同时回退2张表到5分钟之前 */

flashback table employees to scn 3775124 enable triggers;

评估分析

同传统恢复技术相比，特别是Exp/Imp技术相比，Flashback table技术具有如下显著优点：

恢复时间快

如果使用传统Imp技术进行恢复，需要先将该表删除，再将全部记录重新加载（Insert操作），并且重新分配空间。而Flashback Table技术是基于UNDO技术，只需将错误的DML操作进行回退，不需要全部记录重新加载（Insert操作），重新分配空间也较少，因此恢复时间更快。

恢复时效性好

传统Imp技术只能将该表恢复到最近一次Exp的时间点，将丢失最近一次Exp时间点到错误DML之间的变化数据。而Flashback Table则是直接恢复到错误DML之前的数据状态，因此恢复的时效性非常好。

恢复操作简捷

如上所见，Flashback Table基本上通过一条命令即可快速恢复被错误DML操作的表。

高可用性良好

由于Flashback Table操作实际上也为一个普通事务。因此，Flashback Table技术还有一个显著特点是：可在数据库可访问状态下进行。即在数据库处于打开状态下，并且所有表包括正在进行Flashback Table的表都处于可访问状态。这样，数据库的高可用性得到极大保障。

最佳实践经验

由于Flashback Table操作为一个普通事务，因此在操作期间，会产生DML排它锁。
统计信息不会被恢复。建议及时更新被恢复表的统计信息。
Flashback Table操作不支持DDL操作，除非DDL操作只是修改了该表的存储属性。
Flashback Table操作会自动维护索引，并保证数据一致性。
Flashback Table不支持系统表、分布式数据库环境下的远程表。

14.5记录级快速恢复

如果用户错误地进行了各种DML（Insert,Delete,Update等）操作时，如何在记录级进行快速恢复？

记录级快速恢复

通过10g/11g的如下两种Flashback技术，可在记录级进行快速恢复：

Flashback Query

10g/11g的Flashback Query技术可使用户查询过去时间点或过去SCN号的记录数据。例如，假设DBA在10：00发现记录last_name = ‘Chung’被错误删除，但知道9：30时记录正常。以下是在记录级进行恢复的流程和语句：

/*+ 查询9：30时last_name = ‘Chung’的记录 */

SELECT * FROM employees AS OF TIMESTAMP

TO_TIMESTAMP(‘2009-10-04 09:30:00’, ‘YYYY-MM-DD HH:MI:SS’)

WHERE last_name = ‘Chung’;

/*+ 恢复last_name = ‘Chung’的记录 */

INSERT INTO employees

(SELECT * FROM employees AS OF TIMESTAMP

TO_TIMESTAMP(‘2009-10-04 09:30:00’, ‘YYYY-MM-DD HH:MI:SS’)

WHERE last_name = ‘Chung’);

DBMS_FLASHBACK包

10g/11g的DBMS_FLASHBACK包具有与Flashback Query相似的功能。区别在于：Flashback Query需要在SQL语句中增加AS OF短语，用于查询过去某个时间点或过去SCN号状态的记录状况，而DBMS_FLASHBACK包可通过DBMS_FLASHBACK.ENABLE_AT_TIME或DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER的调用，将数据库设置为过去某个时间点或过去SCN号，而现有SQL语句不用进行任何改动，就可直接查询指定过去时间点或SCN号的记录状况。

例如，通过DBMS_FLASHBACK包的使用，上述场景的恢复流程如下：

/*+ 将数据库设置为9：30的状态 */

EXEC dbms_flashback.enable_at_time(TO_TIMESTAMP(‘2009-10-04 09:30:00’, ‘YYYY-MM-DD HH:MI:SS’));

/*+ 为如下语句open cursor C1 */

SELECT * FROM employees

WHERE last_name = ‘Chung’;

Fetch C1 into …

/*+ 将数据库恢复为当前状态*/

EXECUTE dbms_flashback.disable;

/*+ 将C1中的记录插入employees */

INSERT INTO employees

(c1中的记录…);

上述脚本中，详细的Cursor使用过程略。

评估分析

同传统恢复技术相比，特别是Exp/Imp技术相比，Flashback Query和DBMS_FLASHBACK技术具有如下显著优点：

恢复时间快

如果使用传统imp技术进行恢复，需要先将该表删除，再将全部记录重新加载（Insert操作），并且重新分配空间。而Flashback Query和DBMS_FLASHBACK技术基于UNDO技术，可将过去时间点或SCN号的记录从UNDO表空间取回，并重新插入到表中即可，因此恢复时间非常快。

恢复时效性好

传统imp技术只能将该表恢复到最近一次exp的时间点，将丢失最近一次exp时间点到错误DML之间的变化数据。而只要UNDO表空间设置合理，Flashback Query和DBMS_FLASHBACK技术可直接恢复到错误DML之前的数据状态，因此恢复的时效性非常好。

恢复操作简捷

如上所见，Flashback Query和DBMS_FLASHBACK技术基本上通过简单命令即可快速恢复被错误DML操作的记录。

最佳实践经验

Flashback Query一般用于少量记录的恢复，而DBMS_FLASHBACK则用于大量表的大量记录的恢复。
Flashback Query和DBMS_FLASHBACK可用于当前数据与历史数据之间的对比分析。
可简化应用设计。例如不需要临时表存储历史数据，直接通过Flashback Query和DBMS_FLASHBACK查询历史数据。
可通过Flashback Query和DBMS_FLASHBACK技术，运行历史数据报表生成等批处理应用。

14.6 Flashback在应用测试方面运用

“我们要升级到10g!”

若干年前一次在给某银行客户介绍10g新特性中讲到Flashback技术时，发现在座的客户有不少是测试人员，于是开始换位思考，从测试人员角度进行叙述了：

“大家从事测试工作，一定会为每一轮的测试数据准备而耗费大量时间吧？甚至数据准备时间还超过真正的测试时间吧？”

当我绘声绘色地讲解完Flashback在应用测试方面的运用之后，突然听到客户测试组的负责人大声嚷嚷：“我们要升级到10g!”—- 弄得在场的客户领导一阵尴尬，呵呵。在国企，特别是国有银行企业，升级数据库哪是那么简单的事情。

罗老师凭什么本事忽悠得客户如此热血沸腾呢？且看下面内容。

传统测试过程

在传统的应用软件测试中，包括UAT测试、SIT测试、回归测试，特别是应用压力测试中，经常会遇到在一轮测试之后，如何进行数据还原的问题。通常情况下，传统模式的处理流程图如下：

测试环境准备，包括基准测试数据准备。
运行测试案例之前，通过Exp或RMAN的backup技术，先将基准测试数据进行备份。
开始进行各种应用测试。
为进行下一轮测试，特别是在回归测试和压力测试中，需要恢复基准数据。为此，需要先对数据库系统进行清理，再通过Imp或RMAN的restore、recover技术进行基准测试数据恢复。
开始下一轮测试。

可见，在传统模式下，大量时间和资源花费在基准测试数据的备份、清理和恢复之中，极大地影响了测试工作本身的效率。

如何通过Flashback技术，有效提高各种应用测试的效率？

Flashback Database技术的另类运用

通过运用Flashback Database技术，采用如下流程，可显著提高各种应用测试的效率：

测试环境准备。包括基准测试数据准备。
运行测试案例之前，记录测试开始时间，系统SCN号或日志序列号
开始进行各种应用测试。
通过Flashback Database技术，将数据库整体快速回退到测试开始之间的时间， SCN号或日志序列号。
开始下一轮测试。

Flashback Database的详细流程和主要操作请见“数据库级的快速恢复”。

评估分析

在应用测试中，充分运用Flashback Database技术，最大的好处是大大提高了测试数据准备和恢复时间。一方面，不再需要进行基准测试数据备份和清理工作，另一方面，Flashback Database的回退效率由于与数据库容量无关，其效率远远高于Imp和RMAN的Restore、Recover操作。

这样，测试和应用开发人员可将主要时间和资源用于应用软件测试工作本身，将大大提高测试工作效率。

于是，就有了上述让客户测试人员热血沸腾的场面。呵呵。

14.7 Flashback在安全审计方面应用

需求分析

在数据库安全性需求日益增强的今天，DBA经常会面临如何快速跟踪分析关键业务数据变更的历史情况；如何进行安全审计；以及在发生误操作情况下，如何进行准确的快速数据恢复等迫切需求。

运用过程

Oracle 10g/11g的Flashback Versions Query和Flashback Transaction Query特性的综合运用，很好地满足了上述需求。

Flashback Versions Query

通过Flashback Versions Query特性，DBA可查询某个表、某条记录在指定时间段或指定SCN号之间的数据变更情况，例如：

/*+ 查询最近5分钟对employees表进行DML操作的情况 */

select versions_xid,versions_startscn, versions_endscn,versions_operation

from employees

versions between timestamp (sysdate – 1/288) and sysdate

Flashback Transaction Query

通过Flashback Transaction Query特性，利用上述Flashback Versions Query返回的xid，例如0200200038020000， DBA可进一步查询相关的事务详细情况，特别是执行回退的UNDO_SQL语句：

/*+ 查询上述事务详细情况，特别是UNDO_SQL语句 */

select operation,undo_sql

from flashback_transaction_query

where xid=HEXTORAW(‘0200200038020000’)

and table_name=’EMPLOYEES’

OPERATION UNDO_SQL

——— ————————————————————–

DELETE insert into “JFV”.”EMPLOYEES_DEMO”(“EMPNO”,”EMPNAME”,”SALARY”) values (‘111′,’Mike’,’655′);

INSERT delete from “JFV”.”DEPARTMENTS_DEMO” where ROWID = ‘AAAP95AAGAAAAAlAAB’;

UPDATE update “JFV”.”EMPLOYEES_DEMO” set “SALARY” = ‘555‘ where ROWID = ‘AAAP93AAGAAAAAVAAA’;

这样，上述两个Flashback特性的综合使用，不仅可以对指定表、指定记录进行历史数据变更进行统计分析，以及安全审计工作，而且在发生误操作情况下，可直接分析出单个可回退的UNDO_SQL语句，避免进行整个表的回退。

评估分析

Oracle具有多种分析数据变更的历史情况、进行安全审计，以及进行数据恢复的技术，例如LogMiner就是典型的基于日志分析、提供上述功能的技术。相比LogMiner等技术，Flashback Versions Query和Flashback Transaction Query是基于UNDO技术，不需要象LogMiner一样，逐个顺序地分析日志文件，因此分析和恢复效率更快捷。而LogMiner则适合于时间更长远、更系统的分析和恢复工作。

最佳实践经验

Flashback Versions Query不支持外部表、系统临时表、系统内部表和视图。
Flashback Versions Query不支持改变表结构的DDL操作。
Flashback Versions Query将过滤掉shrink操作。
当表、用户被删除之后，Flashback Transaction Query将不返回这些表名和用户名，而是返回相应的系统内部表编号和用户编号。
Flashback Transaction Query技术运用时，最好使数据库运行在supplemental log data方式下，保证Oracle提供更全面的日志信息，例如chained row信息等。

Alter database add supplemental log data;

14.8 Flashback在容灾方面运用

需求分析

作为Oracle容灾技术和最高级别的数据保护方案，Data Guard提供了一种管理、监测和自动运行的体系结构，用于创建、维护和管理一个或多个备用数据库，从而为各种自然灾害、人为错误、系统坏块（Corruption）等提供完备的数据保护能力。

在Data Guard环境中，用户经常会提出如下两种需求：

如何提高备用数据库利用率？

除Data Guard正常容灾功能之外，是否能打开备用数据库，进行各种开发、测试、报表等工作，从而充分提高备用数据库利用率？

如何快速恢复生产系统？

当灾难发生时，灾备系统将被故障切换（Failover）为新的生产系统。此时，假设原有生产系统服务器能恢复工作，且大量数据并未丢失，是否能不重新部署原生产系统数据，而通过某种技术快速恢复原生产系统数据，使之成为新生产系统的灾备系统，并进一步希望通过角色切换（Switchover）功能，恢复原生产系统的生产角色？

Flashback技术运用过程

在10g/11g中，Flashback技术与Data Guard技术进行了完美的结合，能充分满足上述两种需求：

可使物理备用数据库以读写方式打开

在Data Guard中，可以将物理备用数据库以读写方式打开，进行各种开发、测试、报表等用途，再利用Flashback Database技术，将数据库回退到读写打开的时间点，恢复物理备份数据库的灾备功能。以下是这种方案的示意图：

其主要流程包括：

在物理备用数据库中先创建一个Restore Point。
将物理备用数据库以读写方式打开。此时物理备用数据库可以进行各种开发、测试、报表等读写操作。同时物理备用数据库继续接收生产系统传输的日志文件，但没有应用（Apply）。即物理备用数据库与生产系统数据库处于数据不同步状态。
通过Flashback Database技术，将物理备用数据库回退到Restore Point时间点。
此时，物理备用数据库开始通过日志应用（Apply），重新与生产系统数据库进行数据同步操作，俗称“追数据”。

快速恢复生产系统

为恢复发生故障的原生产系统，传统做法是重新通过RMAN方式，将新生产系统的数据恢复到原生产系统，并建立为新容灾系统。此方法因数据量庞大，而导致新容灾系统搭建时间的漫长。而通过Flashback Database技术，则可快速恢复生产系统，其主要流程如下：

通过Flashback Database技术，将原生产系统数据快速退回到灾难发生之前的状态。
通过传输和应用新生产系统的日志，将原生产系统的数据与新生产系统数据同步，快速建立新容灾系统。
通过Switchover快速恢复原生产系统。

上述详细过程，可参见《Oracle Data Guard Administrator》等文档。

评估分析

10g/11g中Flashback技术与Data Guard技术的完美结合，可使用户得到如下益处：

充分提高备用数据库利用率

通过周期性地将物理备用数据库以读写方式打开，并通过Flashback Database进行回退和日志同步，既可提供各种开发、测试、报表等功能，又可定期保持备用数据库与生产数据库的数据同步。

快速恢复生产系统

通过Flashback Database技术，可避免恢复生产系统时的数据重新加载，有效提高了生产系统的恢复效率。

最佳实践经验

Flashback Database只支持物理备用数据库，而不支持逻辑备用数据库。
将物理备用数据库以读写方式打开的方式，一般适合于数据同步时效性不高的应用。例如，上午和下午以读写方式打开，提供开发、测试、报表等功能，而中午和夜间恢复到日志同步状态。
如果数据同步时效性要求非常高，则10g的物理备用数据库不适合。可考虑11g的Active Data Guard技术或10g的逻辑备用数据库。

14.9 Flashback与传统数据恢复技术综合运用

Flashback与RMAN

Flashback主要针对人为错误进行快速恢复，并运用在应用测试、安全审计和Data Guard环境等领域，而且由于大部分Flashback技术是基于UNDO技术，因此恢复的时间有限，一般用于DBA在错误发生第一时间情况下的快速恢复。

而作为Oracle最传统、最经典的数据库物理备份恢复技术，RMAN则是主要用于防范存储介质的物理故障，以及更长远时间的恢复操作。同样地，RMAN也提供了丰富的备份和恢复技术内容。例如各种全库、增量备份策略和技术，特别是10g的快速增量技术（Fast Incremental Backup）、快速恢复区（Fast Recovery Area）、新的备份压缩技术等，以及在全库、表空间、数据文件、数据块、控制文件、SPFILE等不同数据级别和数据类型的恢复技术等。

总之，Flashback与RMAN侧重点不同，是互为补充、相辅相成的关系。在重要生产系统中，Flashback与RMAN都应得到充分应用。

Flashback与Exp/Imp(Data Pump)

Exp/Imp(Data Pump)除具有全库、模式、表等不同级别的数据恢复功能之外，还可广泛运用在数据归档、数据迁移、数据库升级等领域。

同样地，Flashback与Exp/Imp(Data Pump)也是侧重点不同，是互为补充、相辅相成的关系。用户可根据实际需要的不同，有针对性地运用Flashback和Exp/Imp(Data Pump)技术。

11g新技术：Total Recall

需求分析

在现代商业社会，企业需要保存大量交易历史数据，用于市场和客户行为分析，从而全面提升自身竞争力。同时，企业也面临更全面的安全合规性检查需求，需要加强对历史数据的安全审计。

在上述Flashback技术中，主要都是基于UNDO技术和Flashback Recovery Area技术，并不能充分满足企业长久甚至永久保持和利用历史记录的目的，而且企业对历史数据的利用和管理应尽量做到对现有应用程序透明，并对现有生产系统应用影响尽可能少。

Oracle 11g的Total Recall技术很好地满足了上述需求。

11g：Total Recall技术概述

Oracle 11g的Total Recall技术实际上基于新的Flashback Data Archive（FDA）技术。以下是FDA技术原理和特性介绍：

Flashback Data Archive技术原理

在Oracle 11g中， Flashback Data Archive为用于保存历史数据的一组表空间。例如，上图针对不同的保存期限，分别设计了1年、2年、5年的FDA区域。11g在表级启动FDA功能，通过新后台进程FBDA，自动将具有FDA特性表的历史记录由UNDO表空间写入FDA区域。

Flashback Data Archive主要流程

创建FDA区域
为指定表启动FDA功能
查询历史记录

例如：

/*+ 创建保存期限为5年，容量为10g的FDA */

CREATE FLASHBACK ARCHIVE fla1

TABLESPACE tbs1 QUOTA 10G RETENTION 5 YEAR;

/*+ 为inventory启动FDA功能 */

ALTER TABLE inventory FLASHBACK ARCHIVE fla1;

/*+ 查询inventory表的历史记录 */

SELECT product_number, product_name, count

FROM inventory AS OF TIMESTAMP TO_TIMESTAMP

(‘2007-01-01 00:00:00’, ‘YYYY-MM-DD HH24:MI:SS’);

Flashback Data Archive主要特性

FDA按照定义的保存期限（Retention）自动进行历史数据的清理，无需人工操作。
FDA对现有生产系统的开销非常小。
FDA可以压缩形式进行存储，降低历史数据的存储开销。
FDA可进行扩容、调整保存期限等维护操作。
FDA不支持导致表结构变化的DDL操作，也不支持对表的Drop和Truncate操作。

Flashback技术综合对比

典型应用场景

以下通过若干典型故障场景中Flashback技术的运用，对多种Flashback技术进行一番总结。

恢复级别	典型故障场景	Flashback技术

数据库级	错误删除用户	Flashback Database
	错误Truncate表	Flashback Database
	错误运行批处理导致部分数据损坏	Flashback Database
表级	错误删除表	Flashback Drop
	错误地书写Where语句，导致记录被误修改	Flashback Table
	将当前数据与历史数据进行比较分析	Flashback Query
记录级	错误运行批处理，并且不知道哪些表被损坏	Flashback Query

更全面的对比分析

以下是各种Flashback技术更全面、更深入的对比：

Flashback技术	主要目的	级别	配置方式	技术原理	恢复期限	适应场景

Flashback Database	快速恢复数据库	数据库级		基于存储在Flashback Recovery Area中的 Flashback log	取决于Flashback Recovery Area容量和db_flashback_retention_target参数	l 大规模数据误操作 l 应用测试 l 与Data Guard综合使用
Flashback Table	整表恢复到指定时间	表级	缺省	基于Undo技术	取决于UNDO表空间大小，UNDO_retention参数	l 各种DML错误的表级恢复
Flashback Query/ DBMS_FLASHBACK包	查询过去时间点的记录	记录级	缺省	基于Undo技术	取决于UNDO表空间大小，UNDO_retention参数	l 恢复错误记录 l 对历史记录进行分析、统计
Flashback Drop	快速恢复Drop Table操作	表级	缺省	Recyclebin(该表所在的表空间)	自动管理（FIFO算法）。由表空间的空闲空间确定	l 错误Drop 表操作
Flashback Versions Query	访问事务历史情况	记录级	缺省	基于Undo技术	取决于UNDO表空间大小，UNDO_retention参数	l 访问事务历史情况 l 安全审计
Flashback Transaction Query	查询UNDO语句	记录级	缺省	基于Undo技术	取决于UNDO表空间大小，UNDO_retention参数	l 查询事务详细情况 l 查询UNDO_SQL语句
11g Total-Recall(Flashback Data Archive)	历史数据存储和利用	表级	需要配置	基于FDA区域	取决于FDA区域表空间大小	l 历史数据长久存储 l 对历史数据的分析、统计 l 安全审计

注意：

大部分Flashback技术是数据库缺省配置的，可在日常管理中直接使用。而Flashback Database、Flashback Data Archive则需要配置。
大部分Flashback技术是基于UNDO技术，因此应全面考虑UNDO表空间大小、UNDO_retention参数的配置，以及确保UNDO表空间处于RETENTION GURANTEE状态。例如可根据需要和资源情况，将UNDO_retention设置到数天，并扩大UNDO表空间，从而保障能恢复到过去更长时间。

本章参考资料及进一步读物

本章参考资料及进一步读物：

序号	资料类别	资料名称	资料概述

1.	Oracle联机文档	《Oracle Administrator’s Guide》第20章之“Recovering Tables Using Oracle Flashback Table”小节	该节专门讲述了如何通过Flashback Table技术对表的意外操作进行恢复。
2.	Oracle联机文档	《Oracle® Database Backup and Recovery User’s Guide》相关章节	作为Oracle联机文档中专门讲述数据库备份恢复的专著，太多篇幅在讲述各种Flashback技术：Flashback Database、Flashback Table、Flashback Drop… …
3.	Oracle联机文档	《Oracle® Database Advanced Application Developer’s Guide》第12章“Using Oracle Flashback Technology”	如何在应用层面实现Flashback技术？本书的本章做了专题描述。
4.	Oracle大学教材	《Oracle Database 10g:New Features for Administrator 》之13课“Flashback Any Error”	从10g开始全面介绍Flashback技术的Oracle大学教材。
5.	Oracle大学教材	《Oracle Database 11g:New Features for Administrator 》之7课“Using Flashback”	Oracle大学11g教材中讲述Flashback新特性的部分。
6.	My Oracle Support	《Master Note For Oracle Flashback Technologies (Doc ID 1138253.1)》	Metalink中有关Flashback技术的资料汇集地。FRA、Flashback Database、Flashback Table、Flashback Drop… …应有尽有。
7.	My Oracle Support	《11g feature: Flashback Data Archive Guide. (Doc ID 470199.1)》	Metalink中介绍11g新特性FDA技术的专门文章。

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Oracle 数据库坏块处理技术

2016/02/18 by admin Leave a Comment

作者为:

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

本文永久地址：https://www.askmac.cn/?p=16580

一天在公司与几位负责紧急救援电话支持服务的同事聊天，当我询问客户主要有哪些求救电话时，他们告诉我最多的求救电话是两类：一类是数据库宕机或挂起，特别是RAC 数据库出现宕机，另外一类则是数据库坏块问题。前者在我意料之中，而后者则有点出乎我的意料。但仔细一想，事实的确可能如此。大家千万别小看数据坏块的处理，从危害程度而言，几个小小数据坏块的确可能导致客户核心数据不可访问，甚至丢失。而从技术角度而言，数据坏块处理涉及的内部机制和处理方法是非常复杂的。为此，Oracle有若干专题文章是讲述数据坏块处理的。

本章我们先从若干案例介绍起，先让大家从不同层面感触一下数据库坏块处理的多样性和复杂性，然后将详细介绍坏块的处理流程，坏块的定位和相关解决方案，例如使用DBMS_REPAIR包或设置10231事件、ROWID扫描方法等。

可怕的数据库坏块

案例1：逻辑坏块导致的坏块

第一个案例来自于国税某系统，笔者在《品悟性能优化》的第十七章曾经“绘声绘色”地叙述过。本书再次摘要该案例主要内容如下：

故障现象和原因

首先，了解到共有18个数据坏块，三个表核心业务表分别有一个数据坏块，其他15个坏块为索引。

其次，了解硬件特别是存储并没有报错，说明很可能是逻辑坏块。

再其次，了解到前一天的RMAN备份顺利完成，意味着RMAN备份集已经包含了数据逻辑坏块。

处理方案和结果

针对上述具体情况，分别制定了不同的处理方案。

首先不能直接通过RMAN进行恢复，因为备份集很可能已经包含了逻辑坏块，如果恢复只能同样恢复成坏块。
针对索引，采取重建索引到新的数据文件的方案，并获得了成功。
针对三个核心业务表，先采取了设置event=”10231 trace name context forever, level 10”，或者通过SKIP_CORRUPTION_BLOCKS方法，试图将坏块之外的数据读出来，但都没有成功。
与应用开发人员进一步沟通，发现其中一张表为汇总统计表，于是采取了重新运行汇总程序的办法，重新生成了该表并移到一个新的物理位置。
为减少数据损失，对剩余2张表采取了ROWID Range Scan技术。其中一个表获得了成功，但1000多万的表丢失了4条记录。而另外一个表却没有成功。
针对最后一张表，只好采用了最后一个不得已的招术：Oracle的内部技术DUL。最终也基本获得了成功，400多万的表丢失了10多条记录。

案例2：CPU损坏导致的坏块

故障现象和原因

该案例来自于某省移动BOSS系统。具体故障现象表现为：数据库实例宕机，数据库也异常关闭。在客户请求Oracle紧急现场救援服务，Oracle工程师赶到现场之后，经过分析alert.log日志发现：Online Redo Log出现坏块，Oracle在发现Redo Log校验失败之后，为保护数据，Oracle主动关闭数据库实例和数据库。

在硬件公司的积极配合下，后来发现导致该故障的最终原因是数据库服务器的CPU损坏，导致Oracle的Online Redo Log被写坏。

处理方案和结果

Oracle工程师在现场评估了问题原因和影响范围之后，最终确定通过RMAN进行数据库的不完全恢复，即只恢复到出现坏块的Online Redo Log的前一个。该数据库已经达到TB级，为此花费了20多个小时才完成了该核心系统的不完全恢复。由于恢复期间，数据库处于Mount状态，意味着业务不得不停顿了20多个小时。更严重的是，由于是不完全恢复，导致丢失了一个多小时的业务数据。

事后，本人在与承担具体抢救任务的同事聊天时，他坦言：其实他当时是恢复到出现坏块的Online Redo Log的前两个，而不是前一个。原因是他担心前一个也有坏块，而Oracle可能没有及时检查出来。如果出现这种不幸，那Oracle数据库还是无法打开，可能要再次进行恢复。他说宁可客户数据多丢一点，也要保证数据库尽快顺利地打开，及时恢复正常业务。他当时还很神秘地告诉我：千万别告诉客户哦，客户还以为只丢了一个日志文件的数据呢。抱歉，哥儿们，今天在这儿泄露你的秘密了。呵呵。

案例3：Oracle Bug导致的坏块

故障现象

2011年3月21日5：10分左右，某银行系统出现异常，具体情况如下：

数据库在预分配空间时出现异常，报空间分配失败
账务流水表出现数据块逻辑读写错误，不可读写，进而中断交易。
smon后台进程不断尝试恢复损坏的数据块，恢复后将实例2自动关闭。
处理方案和结果

Oracle公司工程师在分析故障原因之后，采取了如下措施：

关闭ORACLE数据库一致性保护校验（初始化参数：db_block_checksum改为false）
删除账务流水表
重建账务流水表

至10：05分，最终恢复了正常业务。

在事故处理过程中，该银行还进行了恢复丢失的账务流水数据、数据追加、数据库多次全库备份、数据一致性验证等工作，在此不赘述。

事故原因分析

根据Oracle公司提交的故障处理报告，最终确定导致数据库出现逻辑坏块的根本原因是Bug所导致。

由故障引发的架构性改造

可见，上述数据坏块故障导致了该银行某系统约5小时的业务停顿。如何有效防范同类事故的发生，引起该银行各级领导和技术人员高度关注，并确定在已经通过存储镜像技术建立同城容灾系统基础上，开展数据库备援系统建设。为此，确定了建设总目标如下：

备援系统将与生产系统建立在同一机房。即不是地理意义上的容灾系统。
在发生类似上述数据坏块故障时，并不是切换到容灾系统。事实上，通过存储镜像技术建立的容灾系统，无法防范数据坏块的传播。
在发生类似上述逻辑坏块故障时，为降低故障影响面，也不是将生产系统直接切换到备援系统。而是优先考虑通过备援系统，快速抢救和恢复被损坏数据。
如果故障影响面较大，才考虑将生产系统直接切换到备援系统。

坏块处理主要流程

导致数据库坏块的原因

Oracle数据库坏块分类物理坏块和逻辑坏块。所谓物理坏块是由于硬件I/O故障或操作系统故障而引起的数据块写入错误，而逻辑坏块通常是Oracle软件问题导致，具体为数据块头信息被写坏，导致头信息与数据块内容不匹配。可见，导致数据库坏块的原因很多，例如主机硬件故障、存储硬件和软件故障、操作系统故障、Oracle软件故障等，甚至应用软件压力过大都可能导致数据库出现坏块。

但有一种坏块现象则是正常现象。即当对某个数据对象以nologging方式实施了操作，例如“alter index <索引名> rebuild nologging”，而事后又对包含该对象的数据文件通过日志进行了recover操作。这样，该对象所对应的数据块将被Oracle标识为corrupt，当访问这些坏块时， Oracle将报ORA-1578错误。这种情况下，虽然可以通过下述方法查询出哪些数据对象出现坏块，但不仅无法通过recover恢复数据，也无法通过其它手段有效地从坏块中抢救数据。客户唯一能做的就是小心、小心，再小心，不要对nologging操作的数据对象进行recover操作！

坏块处理主要流程

区区几个数据库坏块，带来的影响可能是致命的。如何提高坏块处理效率，降低坏块影响范围？就象世界处理所有紧急突发事件一样，一定要事先有预案和处理流程。以下就是Oracle公司提供的坏块处理主要流程图：

下面我们就按此流程图展开更详细的描述：

确定问题范围

首先，一旦发现出现数据库坏块，应该记录下有关坏块的所有信息，包括alert.log文件和trace文件记录的信息，确定坏块涉及的范围。例如应该评估是单个数据坏块，还是因为对nologging操作的数据对象进行recover操作之后引起的大量坏块。

此时，Oracle建议最好能通过DBVERIFY工具对坏块所在的数据文件和其它文件进行扫描，分析是否有更多坏块的存在，从而更准确地确定问题范围。如果我们获取了详细的数据文件/坏块清单，我们就可有的放矢，显著提高坏块处理效率。

Oracle建议的一些最佳实践经验如下：

完整记录原始的坏块出错信息，以及遇到坏块的应用模块信息。
将首次遇到坏块的几小时至当前时间的log信息抽取出来，单独保存为一个文件进行重点分析。
将log文件中涉及的trace 文件进行保存。
了解硬件和操作系统级是否存在报错信息。
查询硬件和存储是否采用异步I/O（ASYNC I/O），磁盘快速写（Fast Write Disk）等技术。
查询当前Oracle备份信息，备份时间、备份类型、备份地点等。
查询数据库是否是归档或非归档模式。

检查和替换有问题的硬件

通常而言，大部分坏块是由于硬件故障而导致的。因此，在在进行坏块数据修复之前，最好对硬件进行充分检查，特别是当出现大量数据坏块或者错误是偶发性的时候。而且，根据Oracle经验，操作系统报错可能会滞后，甚至即便操作系统检查正常，也不代表硬件就一切正常。

因此，在坏块数据修复之前，最好能将有故障或疑似有故障的硬件进行替换或修复。如有可能，最好将故障存储设备的数据文件移到正常的存储设备。具体步骤如下：

步骤如下：

将表空间设置为offline状态。例如：

SQL> alter tablespace userdata offline;

通过操作系统命令移动或复制数据文件。例如：

cp /u01/oradata/userdata01.dbf /u01/oradata/userdata01.dbf

或

mv /u01/oradata/userdata01.dbf /u01/oradata/userdata01.dbf

执行 alter tablespace rename datafile命令。例如：

ALTER TABLESPACE userdata RENAME DATAFILE

‘/u01/oradata/userdata01.dbf’

TO ‘/u01/oradata/userdata01.dbf’;

该命令只适合于移动非SYSTEM表空间的数据文件以及不包含活跃(active)undo、temporary的数据文件。

将表空间设置为online状态。例如：

SQL> alter tablespace userdata online;

可将原来的数据文件删除。例如：

rm /u01/oradata/userdata01.dbf

确定坏块影响的数据库对象

接下来的第三个重要步骤就是确定坏块影响的数据库对象，该步骤同样非常重要。在后面叙述坏块恢复操作时，大家就会看到：不同类型数据库对象的坏块，处理方法是完全不同的。更重要的是：大家千万别搞错坏块所在的数据文件，以及坏块所包含的数据库对象。否则，连恢复的数据库对象都搞错了，那可就是错上加错了。呵呵。

为此，Oracle官方建议最好能制定如下一张坏块信息表，以便进行坏块信息记录和处理过程跟踪：

下面将详细介绍该表格的各项内容及相关术语，以及信息获取办法：

Original Error

即系统记录的原始错误信息，包括ORA-1578 / ORA-1110 , ORA-600及该错误的相关参数等。

Absolute File# &AFN和Relative File# &RFN

Absolute File#表示绝对文件号，简称&AFN，表示数据库级的文件编号。而Relative File#表示相对文件号，简称&RFN，表示表空间级的文件编号。

通常而言， Oracle从8i开始，绝对文件号和相对文件号就是相同的了，除非数据库是从Oracle 7版升级和迁移而来。通过如下语句可查询出数据库的所有表空间和对应的绝对文件号和相对文件号：

SELECT tablespace_name, file_id “AFN”, relative_fno “RFN” FROM dba_data_files;

&FILENAME

即包含坏块的数据文件名。

即出现坏块的数据块编号。

&TSN和&TABLESPACE_NAME

即出现坏块的表空间编号和表空间名称。

上述&AFN、&RFN、&FILENAME、&BL、&TSN和&TABLESPACE_NAME等信息，在出现坏块的原始错误信息中均可获取，例如，出错信息如下：

ORA-01578: ORACLE data block corrupted (file # 7, block # 12698)

ORA-01110: data file 22: ‘/oracle1/oradata/V816/oradata/V816/users01.dbf’

则：

&AFN : “22” (from the ORA-1110 portion of the error)

&RFN : “7” (from the “file #” in the ORA-1578)

&BL : “12698” (from the “block #” in the ORA-1578)

&FILENAME: ‘/oracle1/oradata/V816/oradata/V816/users01.dbf’

&TSN、&TABLESPACE_NAME 则通过如下语句获取：

SELECT ts# “TSN” FROM v$datafile WHERE file#=&AFN;

SELECT tablespace_name FROM dba_data_files WHERE file_id=&AFN;

&TS_BLOCK_SIZE可通过如下语句获取：

SELECT block_size FROM dba_tablespaces WHERE tablespace_name = (SELECT tablespace_name FROM dba_data_files WHERE file_id=&AFN);

另外，如果v$datafile视图不包括出错的&AFN号，并且&AFN号大于DB_FILES初始化参数，则该文件应该是TEMPFILE。为此，可通过如下语句查询出该文件名：

SELECT name FROM v$tempfile WHERE file#=(&AFN – &DB_FILES_value);

也能通过如下语句，查询出TEMPFILE的&AFN号和&RFN号：

SELECT tablespace_name, file_id+value “AFN”, relative_fno “RFN”

FROM dba_temp_files, v$parameter

WHERE name=’db_files’;

Segment Type，Segment Owner, Segment Name

即坏块的数据段类型、属主名和数据段名称，基于&AFN和&BL值，通过如下语句可查询出这些信息：

SELECT tablespace_name, segment_type, owner, segment_name

FROM dba_extents

WHERE file_id = &AFN

and &BL between block_id AND block_id + blocks – 1;

如果坏块是TEMPFILE，则上述查询的Segment Type值将为“TEMPORARY”，其它字段将为空。

如果上述查询没有返回记录，则坏块就位于本地化管理表空间（Locally Managed Tablespace，简称LMT）的段头（Segment Header）。针对这种情况，Oracle不仅会在alert.log中进行记录，而且通过如下语句可获得进一步信息：

SELECT owner, segment_name, segment_type, partition_name

FROM dba_segments

WHERE header_file = &AFN

and header_block = &BL;

Related Object，Recovery Options

即相关数据对象名称和恢复可选方案。限于篇幅，我们仅罗列常见类型的数据对象的处理：

TABLE

若坏块所在的数据对象为SYS用户下的数据字典表，建议联系Oracle技术支持部门。此时，整个数据库通常需要进行恢复。

若坏块位于普通表或分区，则查询相关索引信息：

SELECT owner, index_name, index_type

FROM dba_indexes

WHERE table_owner=’&OWNER’ AND table_name=’&SEGMENT_NAME’;

并进一步确定该表是否主键存在：

SELECT owner, constraint_name, constraint_type, table_name

FROM dba_constraints

WHERE owner=’&OWNER’ AND table_name=’&SEGMENT_NAME’ AND constraint_type=’P’;

如果有主键，再确定是否有访问该主键的外键存在：

SELECT owner, constraint_name, constraint_type, table_name

FROM dba_constraints

WHERE r_owner=’&OWNER’ AND r_constraint_name=’&CONSTRAINT_NAME’;

针对普通表或分区的恢复，有如下两种策略：第一种是通过重建表的方式抢救数据。第二种则是通过DBMS_REPAIR包将坏块进行标识，将坏块进行隔离，不影响坏块之外数据的访问。后面还将详细叙述该过程。

TABLE PARTITION

若坏块位于分区表（TABLE PARTITION），则查询是那些Partition受到影响：

SELECT partition_name

FROM dba_extents

WHERE file_id = &AFN AND &BL BETWEEN block_id AND block_id + blocks – 1;

其它操作则同上述普通表的处理，例如查询该表的索引、主键、外键信息等。

针对分区表的恢复，除上述重建等策略之外，若坏块都位于某一个分区，还可以通过如下的分区交换（exchange）方式，将该坏块数据交换到某个临时表：

Alter table <table_name> exchange partition <partition_name> with table <Temp_table_name>;

这样，DBA可以专注在这个临时表上进行坏块数据的处理，而该表的其它分区可以正常提供服务。

INDEX

若坏块所在的数据对象为SYS用户下的数据字典表上的索引，建议联系Oracle技术支持部门。

若坏块位于普通表或分区上的索引，则查询该索引所在表：

SELECT table_owner, table_name

FROM dba_indexes

WHERE owner=’&OWNER’ AND index_name=’&SEGMENT_NAME’;

并查询该索引上是否定义了Constraint:

SELECT owner, constraint_name, constraint_type, table_name

FROM dba_constraints

WHERE owner=’&TABLE_OWNER’

AND constraint_name=’&INDEX_NAME’;

若该索引为主键，则查询是否有访问该主键的外键存在：（本文永久地址：https://www.askmac.cn/?p=16580）

SELECT owner, constraint_name, constraint_type, table_name

FROM dba_constraints

WHERE r_owner=’&TABLE_OWNER’ AND r_constraint_name=’&INDEX_NAME’;

针对索引的恢复，最好的办法就是重建（rebuild）索引，后面还将详细叙述该过程。

INDEX PARTITION

若坏块位于分区索引，则查询哪些分区受到影响：

SELECT partition_name

FROM dba_extents

WHERE file_id = &AFN AND &BL BETWEEN block_id AND block_id + blocks – 1;

其它操作则同上述普通索引的处理，例如查询该索引所在表、主键、外键信息等。

同样地，针对分区索引的恢复，最好的办法就是重建（rebuild）索引，例如：

ALTER INDEX <Index_Name> REBUILD PARTITION <Partiton_Name>;

TEMPORARY

若坏块位于临时表空间（TEMPORARY），则坏块并没有影响到永久数据对象，例如表、索引等。此时，应查询出使用该临时表空间的所有用户：

SELECT username FROM dba_users

WHERE temporary_tablespace=’&TABLESPACE_NAME’;

针对临时表空间的恢复，最好的办法就是创建一个新的临时表空间，并将受到影响的用户的临时表空间设置为新的临时表空间。例如：

CREATE TEMPORARY TABLESPACE temp2

TEMPFILE ‘/u01/oradata/temp02.dbf’ SIZE 500M

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M;

Alter user <user_name> temporary tablespace temp2;

其它数据类型，例如ROLLBACK、CACHE、CLUSTER、LOBINDEX、LOBSEGMENT、、TYPE2 UNDO、其它数据对象等，就联系Oracle技术支持部门，或请见《Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g [ID 28814.1]》

选择合适的方法进行数据恢复和抢救

接下来的第四个步骤：我们终于要进行实际的数据恢复和抢救了。但这一步骤太复杂了，我们不得不另辟下面一节展开详细描述。

坏块处理八卦图

所谓“选择合适的方法进行数据恢复和抢救”，就是根据坏块所处数据对象的不同类型，例如：CACHE、CLUSTER、INDEX PARTITION、INDEX、LOBINDE、LOBSEGMENT、ROLLBACK、TABLE PARTITION、TABLE、TEMPORARY、TYPE2 UNDO、其它数据对象等，合理制定策略和具体方法进行数据恢复和抢救。

以下就是本人根据Oracle若干篇坏块处理文档总结的数据坏块处理八卦图：

下面将详细描述上述八卦图：

首先判断坏块影响的数据库对象是否是已经不使用的数据对象了，如果是，则啥也不用做了。
其次，判断坏块影响的数据库对象是否处于临时表空间，如果是，则参照上述内容：创建一个新的临时表空间，并将受到影响的用户的临时表空间设置为新的临时表空间。
第三，如果坏块影响的数据库对象是索引，则进一步判断索引所在的表是否也有坏块。如果有，则先解决表的坏块问题。如果没有，则可以通过索引重建方式进行恢复。

若该索引有外键存在，则需要按如下步骤进行：

– For each foreign key

ALTER TABLE <child_table> DISABLE CONSTRAINT <fk_constraint>;

– Rebuild the primary key using

ALTER TABLE <table> DISABLE CONSTRAINT <pk_constraint>;

DROP INDEX <index_name>;

CREATE INDEX <index_name> .. with appropriate storage clause

ALTER TABLE <table> ENABLE CONSTRAINT <pk_constraint>;

– Enable the foreign key constraints

ALTER TABLE <child_table> ENABLE CONSTRAINT <fk_constraint>;

如果是分区索引，则重建索引语句如下：

ALTER INDEX … REBUILD PARTITION …;

需要注意的几点是：

（1）尽量不要使用“ALTER INDEX .. REBUILD”语句去重建非分区索引，因为该语句可能通过已经含有坏块的旧索引数据进行重建，而“ALTER INDEX … REBUILD ONLINE”和“ALTER INDEX … REBUILD PARTITION …”则不会通过已经含有坏块的旧索引数据进行重建，因此应以后两种语句方式进行索引重建。

（2）假设有坏块的索引字段是另外一个复合索引字段的子集，则Oracle可能利用该复合索引的数据进行重建。若该复合索引也有坏块，那就太不幸了。此时，最好将这两个索引都删除掉，并重建。

（3）在重新创建索引时，一定要正确设置相关存储属性，例如将新索引创建在确保没有硬件故障的表空间中。

第四，此时可考虑数据库的完全恢复了。但应该满足如下条件：
数据库处于归档状态
备份数据是完整的

建议通过dbv程序对备份数据检查其完整性。如果最新备份数据也含有坏块数据，则需要查找更旧的备份数据。

归档日志必须是完整的

从备份数据到当前时间的归档日志必须是完整的。

联机日志必须是完整的
没有对实施了nologging操作的数据对象进行recover操作。

例如，若坏块只出现在少量数据块上，则建议进行数据块级恢复。以下是数据块级恢复的相关命令：

blockrecover datafile 8 block 13;

Select * from v$database_block_corruption

blockrecover corruption list;

请注意：数据块级恢复只能做到完全恢复，而不能做到不完全恢复。

若坏块只出现在少数几个数据文件上，则建议进行数据文件级恢复。以下是数据文件级恢复的步骤和相关命令：

— 将含坏块的数据文件设置为OFFLINE状态

ALTER DATABASE DATAFILE ‘name_of_file’ OFFLINE;

— 将该文件复制到安全位置，以防备份数据也包含了坏块

cp < name_of_file > <安全位置>

— 从最新的备份数据中restore该文件至安全位置

命令略

— 通过DBVERIFY检查该文件是否包含坏块

命令略

— 假设该文件不包含坏块，则对该文件目录进行RENAME操作：

ALTER DATABASE RENAME FILE ‘old_name’ TO ‘new_name’;

— 对该文件进行recover操作

RECOVER DATAFILE ‘name_of_file’;

— 将该数据文件恢复为ONLINE状态

ALTER DATABASE DATAFILE ‘name_of_file’ ONLINE;

若坏块出现在多个数据文件上，则可以考虑进行数据库级恢复。以下是数据库级恢复的步骤和相关命令：

— 关闭数据库

Shutdown (Immediate or Abort)

— 将所有文件复制到安全位置，以防备份数据也包含了坏块

cp < name_of_file > <安全位置>

— 从最新的备份数据中restore所有文件至安全位置，但不要restore控制文件和联机日志文件

命令略

— 通过DBVERIFY检查所有文件是否包含坏块

命令略

— 将数据库启动到mount状态

Startup MOUNT

— 假设所有文件不包含坏块，则对被改动位置的文件进行RENAME操作：

ALTER DATABASE RENAME FILE ‘old_name’ TO ‘new_name’;

— 确保所有文件处于ONLINE状态：

ALTER DATABASE DATAFILE ‘name_of_file’ ONLINE;

— 对数据库进行recover操作

RECOVER DATABASE

— 打开数据库

ALTER DATABASE OPEN;

数据库完全恢复之后，建议对受影响的数据对象进行完整性检查，例如：

ANALYZE <table_name> VALIDATE STRUCTURE CASCADE;

确认是否有数据和索引不匹配的情况存在。进一步，建议在应用级检查数据的逻辑完整性。

第五，如果上述完全恢复仍然不能恢复坏块数据，而且被损坏的表为关键业务数据，则此时需要考虑尽可能先确保这些表的正常对外访问，并且从这些表中抢救尽可能多的数据。

此时，可供选择的办法包括：

通过DBMS_REPAIR包或设置10231事件，抢救坏块之外数据。
通过ROWID扫描方法，抢救坏块之外数据。

由于这两项技术较为复杂，我们将在下面专辟章节讲述。

DBMS_REPAIR包或设置10231事件

概述

通过DBMS_REPAIR包或设置10231事件，抢救坏块之外数据的方法，实际上是针对Oracle不同版本而言（本文永久地址：https://www.askmac.cn/?p=16580）：

Oracle 8i之上版本

通过DBMS_REPAIR.SKIP_CORRUPT_BLOCKS过程，对表设置SKIP_CORRPUPT标志，达到绕过坏块读取正常数据的目的。

Oracle 7到Oracle 8.1版本

通过设置10231事件，达到绕过坏块读取正常数据的目的。该技术在Oracle 7.2之前，一般只针对逻辑坏块（Soft Corrupt），而无法针对因介质损坏而造成的物理坏块（Physical Corrupt）。在Oracle 7.2之后，虽然也增强了对物理坏块的至此和，但仍然不能保证能绕过所有类型的坏块。

对广大客户和现有Oracle版本而言，当然主要将使用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS技术，但在本书中我们仍然将介绍设置10231事件技术。

欲使用这两类技术，必须满足如下条件：

坏块所在的表必须是普通表，而不能是系统数据字典表。
最好在Oracle技术支持部门建议和指导下，采用这两类技术。
已经确定了如何重建或抢救数据的办法。例如，Export，或者“create tables as select…”。
已经计划好了抢救数据的停机时间窗口。另外，如果有可能，最好能有一份坏块所在表的复制数据，这样可以专注在这份复制数据上进行数据抢救工作。
整个数据库有备份数据
已经准备好了重建该数据坏块表的SQL脚本，包括索引、限制、触发器等，以及相关的物理存储属性参数。

实施过程

SKIP_CORRPUPT标志的设置

通过如下语句，可对坏块所在表进行SKIP_CORRPUPT标志的设置：

SQL> connect /as sysdba;

SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(<用户名>,<表名>);

这样，可通过“CREATE TABLE AS SELECT”、“or ALTER TABLE <> MOVE”、Export等技术，将非坏块数据进行抢救，例如：

SQL> CREATE TABLE salvage_emp AS SELECT * FROM corrupt_emp;

设置SKIP_CORRPUPT标志之后，若进行了跳过坏块的操作，Oracle将在相关trace文件中进行记录，例如：

table scan: segment: file# 6 block# 11

skipping corrupt block file# 6 block# 12

欲清除SKIP_CORRPUPT标志，则执行如下语句：

SQL> connect /as sysdba;

SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(<用户名>,<表名>, flags=>dbms_repair.noskip_flag);

值得注意的是：DBMS_REPAIR.SKIP_CORRUPT_BLOCKS也可针对索引进行设置，但Oracle进行index range scan操作时，只对非根节点的叶节点进行坏块跳跃，而对枝节点和根结点并不进行坏块跳跃。

10231事件的设置

10231事件的设置可以在session或instance级分别进行。如果采用“CREATE TABLE AS SELECT”或“or ALTER TABLE <> MOVE”进行数据抢救，则在session设置即可。如果采用Export进行数据抢救，则应在instance级进行设置。

例如，以下语句在session级设置10231事件：

SQL> ALTER SESSION SET EVENTS ‘10231 TRACE NAME CONTEXT FOREVER, LEVEL 10’;

此时，可通过“CREATE TABLE AS SELECT”、“or ALTER TABLE <> MOVE”、Export等技术，将非坏块数据进行抢救，例如：

SQL> CREATE TABLE salvage_emp AS SELECT * FROM corrupt_emp;

欲在instance级进行设置，则在初始化文件init.ora或spfile.ora文件中进行如下设置，并重启数据库：

event=”10231 trace name context forever, level 10″

抢救数据之后的处理

一旦将数据抢救完毕，例如重建新表，或者将数据export出来，则应进行如下事后处理：

对被抢救数据进行备份
保存重建表、索引的SQL脚本
将诊断和处理过程中，Oracle技术支持人员需要的相关诊断信息加以保存
删除10231事件或将清除SKIP_CORRPUPT标志
对原来有问题的表进行RENAME或DROP操作。如果空间富裕，最好是RENAME操作。
通过import操作等重建原表。
重建相关索引、触发器等其它对象

ROWID扫描方法

上述通过DBMS_REPAIR包或设置10231事件，抢救坏块之外数据的方法，相比即将介绍的ROWID扫描方法，更为简洁。但上述方法只适合于出现ORA-1578的情况，而且根据本人的经验，该方法经常不能有效进行数据抢救。因此，下面我们将详细介绍ROWID扫描方法。

ROWID简介

为有效使用ROWID扫描方法，我们先需要介绍一下ROWID的格式。ROWID表示每条记录在数据库中的的物理地址，在Oracle 8i之后，ROWID被表示为18位的数字字符串

‘OOOOOOFFFBBBBBBSSS’

其中：

OOOOOO：以Base 64 Encoding 编码格式表示的数据对象序号
FFF：以Base 64 Encoding 编码格式表示的相对文件号
BBBBBB：以Base 64 Encoding 编码格式表示的数据块号
SSS：以Base 64 Encoding 编码格式表示的slot或row号。

通过如下函数，可创建一条记录的ROWID：

function ROWID_CREATE(rowid_type IN number,

object_number IN number,

relative_fno IN number,

block_number IN number,

row_number IN number)

return ROWID;

— rowid_type – type (restricted=0/extended=1)

— object_number – data object number

— relative_fno – relative file number

— block_number – block number in this file

— row_number – row number in this block

ROWID扫描方法原理

以下就是该技术流程图和示意图：

即在定位坏块之后，通过DBMS_ROWID包去生成坏块所处的最小ROWID（LOW_RID），以及最大ROWID（HIGH_RID），例如：

— 最小ROWID

SELECT dbms_rowid.rowid_create(1,<DATA_OBJECT_ID>,<RFN>,<BL>,0) LOW_RID from DUAL;

— 最大ROWID

SELECT dbms_rowid.rowid_create(1,<DATA_OBJECT_ID>,<RFN>,<BL>+1,0) HI_RID from DUAL;

针对普通表，通过如下命令抢救数据：

CREATE TABLE salvage_table AS SELECT /*+ ROWID(A) */ * FROM <owner.tablename> A WHERE rowid < ‘<low_rid>’ ;

INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM <owner.tablename> A WHERE rowid >= ‘<high_rid>’ ;

针对分区表，通过如下命令抢救数据：

CREATE TABLE salvage_table AS

SELECT /*+ ROWID(A) */ *

FROM <owner.tablename> PARTITION (<partition_name>) A

WHERE rowid < ‘<lo_rid>’

;

INSERT INTO salvage_table

SELECT /*+ ROWID(A) */ *

FROM <owner.tablename> PARTITION (<partition_name>) A

WHERE rowid >= ‘<hi_rid>’

但是，如果坏块处于表段头（Segment Header），ROWID扫描法则无用武之地了。通过如下语句，可知道坏块是否处于表段头：

select file_id,block_id,blocks,extent_id

from dba_extents

where owner='<owner>’

and segment_name='<table_name>’

and segment_type=’TABLE’

order by extent_id;

FILE_ID BLOCK_ID BLOCKS EXTENT_ID

——— ——— ——— ———

8 94854 20780 0 <- EXTENT_ID ZERO is segment header

即上述语句中，如果EXTEND_ID为0，则表示是表段头。

如何从坏块中抢救数据？

首先，Oracle公司认为，既然数据已经坏了，坏块数据被完全抢救出来的可能性就微乎其微了。即便这样，可供选择的办法有：

通过索引从坏块中抢救数据

通过ROWID扫描法，可以通过索引从坏块中抢救被索引字段的数据。以下就是详细过程：

如果需要抢救的字段是非空值（Not Null）字段，则使用Fast Full Scan访问方式：

SELECT /*+ INDEX_FFS(X <index_name>) */

<index_column1>, <index_column2> …

FROM <tablename> X

WHERE rowid >= ‘<low_rid>’

AND rowid < ‘<hi_rid>’ ;

其中，<low_rid>、<hi_rid>通过上述dbms_rowid.rowid_create语句产生。

如果需要抢救的字段是允许空值（Null）字段，则不能使用Fast Full Scan，而必须使用Range Scan访问方式。为此，必须设置索引前缀字段的最小值条件，才能确保使用Range Scan访问方式：

SELECT /*+ INDEX(X <index_name>) */

<index_column1>, <index_column2> …

FROM <tablename> X

WHERE rowid >= ‘<low_rid>’

AND rowid < ‘<hi_rid>’

AND <index_column1> >= <min_col1_value>;

这样，如果坏块所在表的索引越多，从索引中抢救数据也可能越多。通过查询dba_ind_columns视图可查询表的索引信息。

通过LogMiner技术

通过LogMiner技术，也可能对坏块数据进行一定的抢救。即从日志文件中找到最初加载到坏块的Insert或Update语句，并从这些语句中抢救出相关数据。

寻求Oracle Support支持

针对表的坏块数据，通过寻求Oracle Support支持，可以通过相关内部工具，对坏块数据进行抢救。欲通过此方法进行进行抢救，请在MOS网站中创建SR。

坏块抢救的最后招数

从容灾数据库进行抢救

如果通过Data Guard配置了容灾数据库，由于Data Guard具有防止坏块传播功能，因此，可考虑在容灾数据库对相关数据对象进行抢救。

从头恢复的一种场景

假设某个数据文件出现坏块，而且数据库没有物理备份，但保留了该数据文件创建之后的所有归档日志，则可以通过如下方式进行恢复：

— 重新创建该数据文件

ALTER DATABASE CREATE DATAFILE ‘….’ [as ‘…’] ;

— 对该数据文件进行恢复操作

RECOVER DATAFILE ‘….’

— 将该数据文件进行恢复为Online状态

ALTER DATABASE DATAFILE ‘….’ ONLINE;

不完全恢复

无论何种数据类型的坏块，都可以通过不完全恢复技术，将整个数据库，或者将坏块所在的表空间恢复到坏块发生之前的某个时刻。但这种技术运用的前提是确定了坏块出现的准确时间，而且将导致整个数据库，或某些表空间数据的大范围回退。

冷备份恢复

假设数据库为非归档模式，并且有完好的冷备份数据，则可以进行冷备份恢复，但只能恢复到冷备份的时间点。也可通过冷备份数据克隆一个数据库，并从此克隆数据库中进行数据抢救。

逻辑恢复

最后一个招数之一就是通过逻辑备份数据（Export，Data Pump）进行恢复了。逻辑恢复只能恢复到备份时间点，不能实现完全恢复。当然，也可通过逻辑备份数据克隆一个数据库，并从此克隆数据库中进行数据抢救。

本章参考资料及进一步读物

本章参考资料及进一步读物：

序号	资料类别	资料名称	资料概述

1.	My Oracle Support	《Master Note for Handling Oracle Database Corruption Issues (Doc ID 1088018.1)》	这就是有关数据库坏块问题的资料入口。坏块的解释；坏块的种类；表、索引、IOT、LOB等各类数据对象坏块的处理；各类坏块诊断工具等，应有尽有。
2.	My Oracle Support	《Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g (Doc ID 28814.1)》	这就是本章主要参考的文档。
3.	My Oracle Support	《Extracting Data from a Corrupt Table using DBMS_REPAIR or Event 10231 (Doc ID 33405.1)》	这是从坏块表中抽取数据的最简单办法。尽管不一定奏效，但值得一试。
4.	My Oracle Support	《Extracting Data from a Corrupt Table using ROWID Range Scans in Oracle8 and higher (Doc ID 61685.1)》	虽然这篇文章介绍的从坏块表中抽取数据方法有点复杂，但效果还是不错的。
5.	My Oracle Support	《Best Practices for Avoiding and Detecting Corruption (Doc ID 428570.1)》	对付坏块最有效的办法就是防患于未然。看看这篇防范坏块的最佳实践经验文章吧：设置DB_BLOCK_CHECKING、DB_BLOCK_CHECKSUM参数；RMAN备份加强逻辑坏块检查；定期运行dbv；定期对主要表进行analyze操作… …
6.	My Oracle Support	《How to identify all the Corrupted Objects in the Database with RMAN (Doc ID 472231.1)》	RMAN可是允许坏块存在的。该文档描述了如何查找RMAN备份数据中的坏块，以及所对应的数据段。
7.	My Oracle Support	《How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY (Doc ID 819533.1)》	该文章介绍根据ORA-1578错误信息，或者根据RMAN和DBVERIFY的坏块信息，查询对应数据对象的办法。

运行维护篇

本人曾在10余年前从数据库应用开发人员转为一个网站的专职DBA，当我把数据库安装好，把备份恢复做好，然后就开始发木了：DBA还应该做什么工作？可能现在很多专职DBA还有类似困惑。Oracle 11g联机文档《Oracle® Database Administrator’s Guide》第一章描述了DBA的11大任务：评估数据库服务器硬件、安装数据库软件、数据库规划、性能监控和优化、备份和恢复数据库、下载和安装补丁… ….

本篇就将从运行维护角度介绍几项DBA应该做的典型工作：数据库健康检查、防止人为错误的FLASHBACK技术运用、版本和补丁管理、数据库空间和碎片管理、数据库安全性评估和加固… …

希望DBA们看过之后，会发出这样的感慨：哦，原来DBA有那么多事情可做哦！

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Extract Datafile From Oracle ASM corrupted diskgroup using PRM-DUL

2015/11/29 by admin 1 Comment

Extract Datafile From Oracle ASM corrupted diskgroup

Amdu

Amdu是从oracle 11g开始加入到Oracle发布版本中的ASM转储工具。除了转储ASM元数据外，amdu的-extract选项还可以从ASM diskgroup中抽取文件。

实际amdu的功能，PRM都具备了，PRM会将ASM元数据分析- ASM Analyze并存入到其内置的数据库中，之后还可以从图形界面上选择哪些文件需要被抽取出来。

以上为PRM的ASM FILE CLONE功能，可以直接从受损的ASM DISKGROUP中克隆出数据文件和归档日志文件。

PRM也支持直接从ASM上的Oracle Database DB数据库中直接拯救表上的数据，对于PRM而言ASM是透明的。

对于ASM上的数据库，根据数据库受损的实际情况考虑使用字典Dictionary(ASM)模式或者非字典Non-Dictionary(ASM)模式。

具体恢复流程为： Tools=>Recovery Wizard=>选择ASM下的字典或非字典模式=>加入所有的ASM Disk后点击ASM analyze

一般ASM下不需要填选block size和offset信息，点击Next，出现Data File列表，勾选SELECT ALL代表所有的数据文件

如果是多个DiskGROUP上有多个Database的情况，需要用户自己去选择对应的数据库的数据文件，之后点选Load，会进入和普通的字典模式没有区别的Schema=>table界面：

ORACLE PRM的GUI图形化交互界面让数据恢复变得很简单！

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Case Study on PRM/DUL Recovery For Oracle Database

2015/11/22 by admin Leave a Comment

PRM is designed for Enterprise Database Recovery, which includes all Oracle DUL data recovery functionalities, and also easy-to-use GUI.

PRM For Oracle Database 3.1 GUI:

PRM almost can recovery Oracle database on all operating system, including:

Linux (RedHat, Centos, Oracle Linux, Suse)，AIX, Solaris, HPUX, Windows 2003 Server/XP/2000/NT。

PRM Support Oracle database which starts from 9i, 10g, 11g to 12c.

Case 1, if there is no backup, on disk segment header is corrupted

SQL> create table prm_test tablespace users as select * from dba_objects;

Table created.

SQL> alter system checkpoint;

System altered.

SQL> select count(*) from prm_test;

  COUNT(*)
----------
     77940

SQL> 
SQL> select header_file,header_block from dba_segments where segment_name='PRM_TEST';

HEADER_FILE HEADER_BLOCK
----------- ------------
          4      1298483

SQL> select name from v$datafile where file#=4;

NAME
--------------------------------------------------------------------------------
/s01/oradata/G10R25/datafile/o1_mf_users_8nx5srgb_.dbf




BBED> set mode edit
        MODE            Edit

BBED> set blocksize 8192
        BLOCKSIZE       8192

BBED> set block 1298483
        BLOCK#          1298483

BBED> set offset 999
        OFFSET          999

BBED>  modify /x 0xffff
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /s01/oradata/G10R25/datafile/o1_mf_users_8nx5srgb_.dbf (0)
 Block: 1298483           Offsets:  999 to 1510           Dba:0x00000000
------------------------------------------------------------------------
 ffff0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 

BBED> sum
Check value for File 0, Block 1298483:
current = 0x18cc, required = 0xe733

SQL> select count(*) from prm_test;
select count(*) from prm_test
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 1298483)
ORA-01110: data file 4:
'/s01/oradata/G10R25/datafile/o1_mf_users_8nx5srgb_.dbf'


SQL> alter session set events '10231 trace name context forever ,level 10';

Session altered.

SQL> select count(*) from prm_test;
select count(*) from prm_test
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 1298483)
ORA-01110: data file 4:
'/s01/oradata/G10R25/datafile/o1_mf_users_8nx5srgb_.dbf'


Start PRM

./prm.sh

Recovery Wizard=》Dictionary Mode, if ASM, then choose Dictionary Mode(ASM) =>select data files (at least including system tablespace datafile and datafile where data located), and click load.

Attention: on AIX HPUX Sparc Solaris, and UNIX platform, choose Big Endian. Linux, Windows, X86 Solaris choose Little Endian

Find your table on the left and right click View

If we PRM show correct data, we recommend you to use DataBridge mode for inserting data back. Right click DataBridge and input connection info, and click DataBridge

As above, it has been successfully extract 77940 rows

CASE 2, No Archive Mode, a datafile has been offline, and related redo log has been overwritten. User can’t online this datafile again.

SQL> archive log list

Database log mode              No Archive Mode

Automatic archival             Disabled

Archive destination            /s01/arch

Oldest online log sequence     343

Current log sequence           348



SQL> select file_name,file_id from dba_data_files where tablespace_name='TBS5';



FILE_NAME                                   FILE_ID

---------------------------------------- ----------

/oracleasm/TBS5.256.844175363.dbf                 6







SQL> alter database datafile 6 offline drop;



Database altered.



SQL> alter system switch logfile;



System altered.



SQL> /



System altered.



SQL> /



System altered.



SQL> /



System altered.



SQL> /



System altered.



SQL> /



System altered.





SQL> recover datafile 6;

ORA-00279: change 34421776 generated at 04/19/2014 19:33:32 needed for thread 1
ORA-00289: suggestion : /s01/arch/1_354_831398352.dbf
ORA-00280: change 34421776 for thread 1 is in sequence #354





Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.





[oracle@vrh8 ~]$ rman target /



Recovery Manager: Release 10.2.0.5.0 - Production on Sat Apr 19 19:49:22 2014
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database: G10R25 (DBID=2696593743)



RMAN> recover datafile 6;



Starting recover at 19-APR-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 devtype=DISK



starting media recovery



unable to find archive log
archive log thread=1 sequence=354
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 04/19/2014 19:49:29
RMAN-06054: media recovery requesting unknown log: thread 1 seq 354 lowscn 34421776





Here we can use PRM to extract all data which can not be online



SQL> select OWNER,SEGMENT_NAME,SEGMENT_TYPE from dba_segments where tablespace_name='TBS5';

OWNER SEGMENT_NAME                   SEGMENT_TYPE

----- ------------------------------ ------------------
SYS   VVVV                           TABLE
SYS   AVE2                           TABLE
SYS   AVE                            TABLE
SYS   ATEST1                         TABLE
SYS   BIN$2KcAMnnvGg/gQKjAvwEbRg==$0 TABLE
hu     TAB1                           TABLE







Start PRM



./prm.sh

Recovery Wizard=》Dictionary Mode, if ASM, then choose Dictionary Mode(ASM) =>select data files (at least including SYSTEM.DBF and data file where data located), and click load.

Attention: on AIX HPUX Sparc Solaris, and UNIX platform, choose Big Endian. Linux, Windows, X86 Solaris choose Little Endian