天灾还是人祸：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掉该数据文件，保证数据库能够正常启动，但该数据文件上的数据丢失。
哪天心情正好，时间正好，便去做这件事吧，更可能的是将这件事压在了箱底。
天灾还是人祸：ORA-01565: error in identifying file '/u01/app/oracle/oradata/eftp/testNS.dbf'相关推荐
- linux查看dat文件权限,ORA-01565: error in identifying file '+DATA/rac/dataile/datfile/system'
环境:RHEL 5.1 32位 ,Oracle 11.2.01 在安装11G RAC建库的时候DBCA出现 ORA-1503 CREATE CONTROLFILE FAILED ORA-01565 ...
- linux查看磁盘 lsdsk,ORA-01565: error in identifying file '+DATA/rac/dataile/datf
环境:RHEL 5.1 32位 ,ORACLE 11.2.01在安装11G RAC建库的时候DBCA出现ORA-1503 CREATE CONTROLFILE FAILEDORA-01565 erro ...
- oracle数据库read only,oracle 报错Linux-x86_64 Error: 30: Read-only file system
本帖最后由 ccton 于 2014-2-18 12:08 编辑 [root@**** hydata]# cat /etc/redhat-release Red Hat Enterprise Linu ...
- oracle00205报错,[Oracle] 数据库启动失败报错 ORA-00205: error in identifying control file
有同事问我,他的数据库启动失败,报错如下: ORA-00205: error in identifying control file, check alert log for more info 这种 ...
- ORA-00205: error in identifying control file, check alert log for more info
ORA-00205: error in identifying control file, check alert log for more info 环境:oracle10gR2 solaris ...
- 是什么引起数据中心机房事故频发，是天灾还是人祸？
前言: 数据中心机房的安全是网络正常运行的前提,它已经成为了人们生活的一部分,数据中心机房一旦发生故障将给企业以及人们带来极大的损失和不便,轻者造成机房设备受损,降低使用寿命:重者造成设备损坏和信息丢 ...
- 阿富汗-天灾与人祸的荒野[天声人语2009年8月25日（火）]
豊かな水が大地を潤す.日本では普通に見る景色のありがたさを.ペシャワール会(本部・福岡)のDVD「アフガンに命の水を」を見て思った.最貧の国で26年にわたって支援を続けてきたNGOの報告である. 丰富 ...
- 加密市场进入寒冬，是“天灾”还是“人祸”?
高通胀的市场环境下,激进加息如期而至.投资者恐慌指数暴涨,风险偏好与流动性的改变,导致风险资产迎来大规模的抛售,加密资产作为风险资产的代表首当其冲. 根据Coinmarketcap的数据显示,截至本周 ...
- [转帖]天灾还是人祸，让你知道最爱是谁？
[转帖]天灾还是人祸,让你知道最爱是谁? 作者:wissEB 299A 235AF3 前天,发生了一件整得全公司所有人都苦不堪言的"悬案"! 事件的起因是区域网内的电脑此起 ...
最新文章
- [LeetCode] [C++] 第一轮刷题总结(持续更新~~~)
- android课程设计录音机,[转载]数字录音机(微机原理与接口技术－课程设计）
- APUE(第七章)进程环境
- 武汉首座无人驾驶电动汽车充电站投入使用
- Ardino基础教程 8_模拟值
- .NET 基金会项目介绍 - ReactiveUI
- 微信喊你来找工作：上千家企业将提供超10万个就业岗位
- web前端开发是干嘛的？
- 不来看看这些 VUE 的生命周期钩子函数？ | 原力计划
- springboot自定义starter启动器
- 使用Excel进行线性规划
- Linux操作系统 - 01 Linux基本命令
- 六级考研单词之路-二十二
- opencv倾斜校正 java,OpenCV实现基于傅里叶变换的旋转文本校正
- 工业版树莓派 CM3
- 昨日关注：40个博客网站排名
- 校验验证码 实现登录验证
- D - Denouncing Mafia DFS
- 如果把一张大图分开matlab,如何把一张大图分开在几张A4纸上打印出来
- tkinter-pack布局详解