在元旦至今，一共使用ODU恢复了两家公司的数据(南京某统计局和广州某钢铁公司)，由于客户不方便将操作信息带走，本文不粘贴操作日志，只描述客户故障及解决方法。下面是两家公司故障描述。

南京某统计局：

故障描述：

客户ORACLE软件安装在本地磁盘，数据库初始化数据文件均放在本地磁盘，业务数据表空间存放在磁盘阵列上，由于本地磁盘RAID5同时坏了2块磁盘，ORACLE_HOME及初始化数据文件全部丢失，只有业务数据表空间的数据文件由于保存在磁盘阵列上而未丢失，而且客户对业务非常的熟悉，并且测试环境有完整的表结构等信息，这种情况就很好恢复了，(ODU只要有数据文件，就可以恢复数据)。

解决方法：

使用ODU直接将业务数据表空间的数据文件内的所有表数据UNLOAD出来，并加载到新的数据库，由于丢失SYSTEM表空间，此时的表名已经该表(例如ODU00001)，表的列明也有所改变(COL0001)，客户根据表内的数据判断是哪张表，然后按照字段顺序将数据INSERT到表名和列明正确的表内，恢复完成。

广州某钢铁公司：

故障描述：

该客户SYSTEM数据文件和业务数据文件损坏(SYSTEM UNDO损坏，SYSTEM数据文件和业务数据文件有坏块)，数据库无法打开，在我们公司介入之前，其他第三方公司尝试恢复(没保留现场)失败，现场被严重破坏，已经无法使用BBED工具恢复。

解决方法：

使用ODU恢复业务用户的所有表信息，并导入到新数据库，由于SYSTEM数据文件没有丢失，此时表名和列名都是正确的，再导入数据后，客户校验数据时发现一张表没有数据，查看EXTENT和OBJECT信息，发现这张表是有数据的，但是不巧的是这个表的表头正好存在一个损坏的数据块上，ODU只能UNLOAD到表结构而不能正确UNLOAD出数据，经过咨询老熊(熊军)，在UNLOAD的时候加上SCANNED参数(UNLOAD TABLE XXX.YYY SCANNED)，成功导出表的数据。

数据已经找回，但是客户的应用程序报ORA-00904错误，经过分析，发现客户的程序调用函数，而ODU只将表的数据UNLOAD了，并不能恢复其他对象，还好客户的SYSTEM数据文件没有丢失，ODU又发挥了专长，将SYS用户的所以表UNLOAD出来，导入到新建的用户(DBDREAM)里，根据ORACLE_HOME/rdbms/admin/catalog.sql文件里的内容，在DBDREAM用户下创建DBA_OBJETS视图，查到所有函数的OBJECT_ID，在根据数据字典查到创建函数的SQL语句，然后重新创建，这个错误解决。

但是紧接着客户的程序又抛出错误，客户在应用程序上增加记录，保存是报保存失败，并没有抛出数据库的错误，无从下手，使用10046追踪后，发现应用程序调用的程序包不存在，通过查询DBDREAM用户下的数据字典(源库导入的)，发现有61个包，按照同样的方法重建这些包，为了避免程序再次报错，将序列也顺便重建(注意START值要放大)，还好客户的业务用户并没有其他对象，减少了很多麻烦。

本文固定链接: http://www.dbdream.com.cn/2013/01/%e8%bf%91%e6%9c%9f%e4%b8%a4%e6%ac%a1odu%e6%81%a2%e5%a4%8doracle%e6%95%b0%e6%8d%ae%e5%ba%93%e5%b0%8f%e8%ae%b0/ | 信春哥，系统稳，闭眼上线不回滚！