天灾还是人祸：ORA-01565: error in identifying file '/u01/app/oracle/oradata/eftp/testNS.dbf'

开发那边说有台测试环境的数据库启动报错，我登上去试了下，startup报出这样的错误：

ORA-01110: data file 4: '/u01/app/oracle/oradata/eftp/testNS.dbf'

ORA-01565: error in identifying file '/u01/app/oracle/oradata/eftp/testNS.dbf'

ORA-27048: skgfifi: file header information is invalid

然后看了下alert日志信息：

orrupt block relative dba: 0x00000001 (file 4, block 1)

Completely zero block found during validating datafile for block range

Reread of blocknum=1, file=/u01/app/oracle/oradata/eftp/testNS.dbf. found same corrupt data

Reread of blocknum=1, file=/u01/app/oracle/oradata/eftp/testNS.dbf. found same corrupt data

Reread of blocknum=1, file=/u01/app/oracle/oradata/eftp/testNS.dbf. found same corrupt data

Reread of blocknum=1, file=/u01/app/oracle/oradata/eftp/testNS.dbf. found same corrupt data

Reread of blocknum=1, file=/u01/app/oracle/oradata/eftp/testNS.dbf. found same corrupt data

2017-07-20T22:00:12.244074+08:00

Errors in file /u01/app/oracle/diag/rdbms/eftp/eftp/incident/incdir_8609/eftp_j002_11132_i8609.trc:

ORA-19563: datafile header validation failed for file /u01/app/oracle/oradata/eftp/testNS.dbf

ORA-01251: Unknown File Header Version read for file number 4

ORA-01578: ORACLE data block corrupted (file # 4, block # 266)

ORA-01110: data file 4: '/u01/app/oracle/oradata/eftp/testNS.dbf'

初步判断，由于坏块导致该数据文件异常，数据库无法启动起来。测试环境没有备份，打算直接将该数据文件offline，然后让开发那边重新导数据进去。

于是我直接offline了该数据文件

alter database datafile 4 offline drop;(非归档环境)

结果再次启动数据库，报错如下：

ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/eftp/redo1.dbf'

ORA-27048: skgfifi: file header information is invalid

Additional information: 2

顿时觉得兴奋异常，仿佛闻到了鲜血的味道。

然后由于当天事情繁多，虽然对于这个问题很亢奋，却没时间静下心来分析该问题。只好先克隆了一份该系统，并将alert日志取了下来，然后让开发那边重新建个实例先使用起来。

今天周一过来收拾好琐事便来细看该问题，在alert日志里发现最早报错信息出现在晚上9点：

Hex dump of (file 4, block 1) in trace file /u01/app/oracle/diag/rdbms/eftp/eftp/trace/eftp_m000_6333.trc

Corrupt block relative dba: 0x01000001 (file 4, block 1)

Completely zero block found during kcvxfh v8

Reading datafile '/u01/app/oracle/oradata/eftp/testNS.dbf' for corruption at rdba: 0x01000001 (file 4, block 1)

Reread (file 4, block 1) found different corrupt data (no logical check)

Hex dump of (file 4, block 1) in trace file /u01/app/oracle/diag/rdbms/eftp/eftp/trace/eftp_m000_6333.trc

Corrupt block relative dba: 0x01000001 (file 4, block 1)

Completely zero block found during reread

可以看到，此处信息明确指出datafile 4这个数据文件，头块信息不对，准确的说，是数据库想写入该数据文件，读取头块信息的时候，发现不了正确的地址信息。

补充下系统环境情况，这套数据库是搭建在新的vsan上面，而不巧的事情是前不久也有一套oracle测试环境出现坏块的情况，所以，我担心是不是vsan环境存在问题，诸如ssd频繁擦写，导致数据库出现物理坏块。

而这次不巧的事情就坏块出现在了数据文件的头部。

但是接下来报出redo01的头块也出现了问题，便让我不甚理解。我只好认为是不遂人愿，屋漏偏逢连阴雨。

尽管我内心深处有点倾向是平台的问题，但为了确保故障的真实性，再次电话确认开发人员，是否做过什么操作，开发人员告诉我，外包公司的人好像在晚上9点左右做过复制数据文件的操作。。然后第二天就报错数据库启动不了。

我的内心是毫无波澜的，即使是看到了下面这些历史命令里面的信息：



原来，我苦苦追寻的数据文件头部坏块问题，竟然是莫名其妙成了他人的制造出来的压缩文件，呜呼哀哉！

大家都是干苦力的民工兄弟，何苦相互为难呢。

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

据上述信息，做一个总结：

由于外包人员的想当然操作，导致数据库的一个数据文件成了压缩文件，此时数据库中再使用该数据文件，便会愤怒的发现，TMD这个文件是什么鬼。也就意味着脏数据是写不到该数据文件中的，那么好了，redo log日志还在等着脏数据写到磁盘上的数据文件中，而脏数据写不到磁盘上，redo日志就没法实现切换，数据库就要hang在那里，于是这成了一个解不开的结。

至于为何第一个redo日志文件的头块也损坏了，八九不离十也是由于上面tar操作导致的，但具体原因尚未知。

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

现在问题来了，测试环境没有备份，遇到这样的情况怎么办？

由于redo报出头块损坏，可能需要将该redo log 进行clear，这样的话，将导致redo中的信息丢失，而由于现在的testNS.dbf文件其实是由之前的testNS.dbf数据文件压缩过来，也就意味着，我及时将当前的testNS.dbf文件解压出来，依然需要redo日志对解压出来的testNS.dbf文件进行恢复，而由于该redo日志文件已经被我clear了，所以将导致该数据文件恢复失败。

于是，最理想的效果就是，redo clear后，offline掉该数据文件，保证数据库能够正常启动，但该数据文件上的数据丢失。

哪天心情正好，时间正好，便去做这件事吧，更可能的是将这件事压在了箱底。