系统情况如下：
1. Oracle版本是10.2.0.3，操作系统是HP-UX PA RISC 64
2. 数据文件存储在裸设备上
3. 需要恢复的表是分区表
4. 在调整存储硬件的时候没有关闭数据库，由于某些不可预知的故障导致某些用户表空间的数据文件write error，然后自动offline了
5. 数据库确实是归档模式，但是有一个每小时删除一次归档的crontab，删除了重新online数据文件需要的所有归档
6. 保留了之前建表时的create脚本
恢复过程如下：
1. DUL使用的init.dul内容：
CONTROL_FILE = control.dul
DB_BLOCK_SIZE = 16384
2. DUL使用的control.dul文件内容
0 1 /somepath/rsystem_01_8g blocks 524161
22 128 /somepath/r_data07_01_32g blocks 2096641
22 134 /somepath/r_data07_02_32g blocks 2096641
22 141 /somepath/r_data07_03_32g blocks 2096641
22 147 /somepath/r_data07_04_32g blocks 2096641
22 153 /somepath/r_data07_05_32g blocks 2096641
22 159 /somepath/r_data07_06_32g blocks 2096641
22 165 /somepath/r_data07_07_32g blocks 2096641
22 171 /somepath/r_data07_08_32g blocks 2096641
22 177 /somepath/r_data07_09_32g blocks 2096641
22 183 /somepath/r_data07_10_32g blocks 2096641
在HP-UX PA RISC中，虽然数据文件是存储在裸设备中的，但是仍然不需要设置需要跳过的字节，跟AIX中DUL相比较，缺少了第4位的4096。
3. 登录DUL
DUL> bootstrap;
DUL> unload table user_name.table_name;
由于system表空间正常，数据字典都存在，因此unload table的过程很简单，并且对于分区表（复合分区表）DUL也是完全胜任的，只需要指定table name，就会自动unload出该表的所有分区以及子分区的数据。
这次DUL大概花了4个小时，unload出120G左右的数据。数据库字符集为ZHS16GBK，字段内容包含中文内容，DUL可以unload出正确的字符。
4. 重新创建表结构，将DUL卸载出的数据再sqlldr到表中。
此步操作在处理位于offline表空间中的表分区时碰到了ORA-14117错误，详细参看How to resolve ORA-14117: partition resides in offlined tablespace文章。
kamus，又dul啦啊
Kamus最近搞恢复搞得多啊。
最近的恢复这么好啊.
我也没想到这么频繁。。。
@老熊
可惜你的ODU没有HP-UX版本的，否则我也准备去试一下了。没准可以帮你比较一下ODU和DUL的unload效率。
@kamus
目前没那个编译环境。以后有机会再编译那个平台的了。
“跟AIX中DUL相比较，缺少了第4位的4096。 ”
因为aix的lv在创建的时候有头块（4k）来管理lv，如果创建lv的时候使用/usr/sbin/mklv -y LVname -T O -w n -s n -r n VGname NumPPs，对oracle来说就是“zero offset”了。
如果在AIX上创建11g DB，那么用带有4k头块的儿歌lv建库，alert会有提示
Tru64 的头块为64k，其他没有 😀
Great! 谢谢Lunar这个注解。
@老熊
建议老熊采用“Cross compiler”的方法（在一个平台上生成另一个平台上的可执行代码），尽快完成其他平台的ODU，为国为民做多贡献 😀
Lunar
@lunar @老熊
这确实是一个很好的方法。帮老熊搜两个链接。
cross compiler mini howto
Cross compiler in wikipedia
事实上，oracle 的所有DUL工具都是在Linux平台上开发，然后采用“Cross compiler”生成了其他平台的可执行程序。
@以前很想搞定cross compiler的, 居然没有整成功, 一样缺少编译环境了.
Kamus, 你有这么多DUL的经验, 有没有比较过AUL和DUL的性能差别啊?
@anysql
我没有你的AUL无限制版。。。想比较也没办法啊 *(
@lunar 呵呵，在这里又看到了你。：）
AUL不会有无限制版本的，只会开个在线帐号给你。
@anysql
呵呵，那好吧，下次再有紧急情况我就申请一个你的在线帐号。 🙂
@anysql
其实我觉得你可以跟DUL学习，做时间限制版，编译完后30天就过期的那种版本。
DUL可以向我学习，做一个态动的许可证机制, 🙂
@anysql
毕竟DUL不是商业工具，只是为了方便大家使用而又不会有泄露给客户长期有效版本的嫌疑就可以了。
恢复用哪个工具其实关系不大, 以下四点比较重要.
1, 客观评估可恢复性
2, 准确预估恢复时间
3, 做好客户保密工作
4, 做好事后支持工作