关于数据库文件损坏风险的提醒
前言
小y最近处理了几起Oracle数据库文件损坏的case,因为某些Bug风险较大,因此不敢有丝毫怠慢,赶紧拿出来分享!希望能够帮助到有需要的朋友!风险提示!
如上图所示,Linux 5/6上的一个已知缺陷,在某些触发条件下,将导致Oracle数据文件出现内容全是0的的坏块。该操作系统上的缺陷,除了会导致Oracle数据库数据文件损坏外,还会导致包括归档日志、在线日志的损坏。而如果是current状态的在线日志发生损坏,那么对于数据库的影响将是致命的。需要引起重视!
BUG触发条件:
当同时满足下列条件下时,会触发一个Linux上的已知缺陷,导致数据库数据文件或归档文件或在线日志文件的损坏:
1、 操作系统为Linux,版本为Redhat 5/6 或Oralce Linux 5/6
2、 数据文件/归档日志/在线日志所在的文件系统采用ext4
3、 数据库参数filesystemio_options=SETALL(为了提升IO性能而设置)
4、 数据库版本从10g到12c
如何修复?
1、临时的,可以通过修改数据库参数来绕开该BUG
filesystemio_options=none或
filesystemio_options=ASYNCH或
filesystemio_options=DIRECTIO
2、进一步的,建议尽快修复Linux操作系统的缺陷
对于Redhat 5
在kernel-2.6.18-238.el5 - RHEL5.6 Errata RHSA-2011-0017 或更高的版本中修复
对于Redhat 6
在kernel-2.6.32-71 或更高的kernel版本中修复
更多内容,可以参考My Oracle Support,参考文档号1487957.1:
ORA-1578 ORA-353 ORA-19599 Corrupt blocks with zeros when filesystemio_options=SETALL on ext4 file system using Linux (Doc ID 1487957.1)
小y已经好几次处理该类型的case,接下来看一个最近的一个CASE。
相关案例分享
小y不是个懂得生活的人,故障处理、性能调优等工作占据了小y的全部生活,剩下的时间就是在补觉(好无趣的人啊)。小y也曾幻想走出门,多交些朋友。但小y不善言谈,帮助他人解决问题就是小y交朋友的典型方式。
最近在微信里,看到jeanron杨建荣的Oracle公众号发表了一篇名为<最近让我焦灼的四个问题>的文章。其中第一个问题就是dataGuard备库老报坏块的问题。报错如下所示
对于这个问题,jeanron已经分析了各种场景,前前后后做了不下十多种测试,基本都排除了,重建了多次,问题还是没能解决。
看完该文章的时候,结合过去所处理的case,小y已经基本上可以断定:
Jeanron很不幸,他遇到了文章一开始我们所提到的Bug了!
虽然和jeanron不熟,但帮助人和交朋友是小y现在很乐意做的事情。
于是小y私信了他,告诉他可能遇到操作系统的Bug了,并让他做了以下检查,很幸运的,小y又一次猜对了。
1、检查操作系统版本
检查结果,满足bug的触发条件Redhat 5.3
2、检查kernel版本:
检查结果,Linux的该Bug在kernel-2.6.18-238.el5以下会触发,
而该Kernel版本为2.6.18-194,满足Bug触发条件
3、检查数据库文件存放的目录:
检查结果,数据库文件存放在/home目录下,该目录是ext4文件系统,满足Bug触发条件
4、检查filesystemio_options参数:
检查结果,数据库参数filesystemio_options为SETALL,即同时支持异步IO和DIRECT IO,,满足Bug触发条件。
5、结论和结果
可以看到,所有触发条件全部满足,至此可以确认命中一开始提到的Linux BUG了。
在调整filesystemio_options=NONE后,jeanron确认问题得到最终解决。
小y很开心,除了解决问题带来的成就感之外,
自己的经验可以帮到客户、帮到朋友,还可以交到朋友,
那不就是小y的追求么!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341