本文主要是介绍关于数据库文件损坏风险的提醒，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

前言

小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的追求么!

这篇关于关于数据库文件损坏风险的提醒的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！