小y最近处理了几起Oracle数据库文件损坏的case,有些某些Bug风险较大,因此不敢有丝毫怠慢,赶紧拿出来分享!希望能够帮助到有需要的朋友!
这一次分享,先重点做风险提示,再附上一个相关案例。
不想被银监会/证监会/保监会等监管机构通报的运维小伙伴们,一定要注意这个风险哦!
BUG触发条件:
当同时满足下列条件下时,会触发一个Linux上的已知缺陷,导致数据库数据文件或归档文件或在线日志文件的损坏:
1、 操作系统为Linux,版本为Redhat 5/6 或Oralce Linux 5/6
2、 操作系统kernel的版本为
3、 数据文件/归档日志/在线日志所在的文件系统采用ext4
4、 数据库参数filesystemio_options=SETALL(为了提升IO性能而设置)
5、 数据库版本从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备库老报坏块的问题。报错如下所示
看完该文章的时候,结合过去所处理的case,小y已经基本上可以断定:
Jeanron很不幸,他遇到了文章一开始我们所提到的Bug了!
虽然和jeanron不熟,但帮助人和交朋友是小y现在很乐意做的事情。
于是小y私信了他,告诉他可能遇到操作系统的Bug了,并让他做了以下检查,很幸运的,小y又一次猜对了。
5、结论和结果
可以看到,所有触发条件全部满足,至此可以确认命中一开始提到的Linux BUG了。
在调整filesystemio_options=NONE后,jeanron确认问题得到最终解决。
小y很开心,除了解决问题带来的成就感之外,
自己的经验可以帮到客户、帮到朋友,还可以交到朋友,
那不就是小y的追求么!
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论0 条评论