这篇文章看起来有点标题党的感觉。

昨天一位网友管理的数据库(版本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修正块的交错之后,至少能导出一部分数据字典了,有了一线希望。

网友仍然在尝试恢复中。

这是一个惨痛的教训,系统一定要做备份,备份的数据一定不要放在与系统同一台服务器上,也一定不要放在同一个硬盘或阵列上,阵列也是不可靠的。

,