这篇文章看起来有点标题党的感觉。
昨天一位网友管理的数据库（版本9iR2，平台Windows），由于存储阵列问题，挂了，再也起不来了。
数据库本来有RMAN做的备份，但不幸的是，备份数据与数据库放在同一台服务器，同一个硬盘上，备份文件不幸地变成了0字节。
数据库在打开时，报ORA-1578错误，错误块为系统表空间文件号1的第417块。这可是系统在自举（bootstrap）时非常重要的一个数据块，具体可以参见eygle的文章《Oracle中独一无二的Cache对象》
使用dbv检查数据文件，发现很多很多的坏块。
我让网友对现有的数据库中的所有文件（数据文件，在线日志文件等）做一个冷备份。然后使用我开发的ODU，dump 文件1的第417块，”神奇的“事情出现了，dump出来的结果显示，这个块头显示这个块的地址居然是文件号1，块号为425，相差了8个块。继续检查发现，这个块附近的连续8个块，都偏移了8个块（均是向后偏移了），而这8个块之后的8个块，又向前偏移了8个块的位置。说的更清楚的就是，这连续的16个块，前8个块和后8个块，他们在磁盘上交换了位置。
My God，这个系统疯了，是存储阵列的问题？还是操作系统的。看起来阵列的问题其可能性更大。
我花了大约20几分钟的时间，修改了一下ODU程序，对copy datafile命令加上了修正数据块交错的功能。网友用copy datafile将SYSTEM表空间的数据文件复制成一个新的文件后，用dbv检查，仍然还是有很多的坏块，不过已经比之前的少很多了。不过从dbv检查的结果来看，有很多的坏块，显示的是全0字节，也就是说，这个块中的所有数据全为0。这样的块，彻底地坏了。
不过用ODU修正块的交错之后，至少能导出一部分数据字典了，有了一线希望。
网友仍然在尝试恢复中。
这是一个惨痛的教训，系统一定要做备份，备份的数据一定不要放在与系统同一台服务器上，也一定不要放在同一个硬盘或阵列上，阵列也是不可靠的。