关于数据库文件损坏风险的提醒

前言

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

时间: 2024-12-07 21:51:11

关于数据库文件损坏风险的提醒的相关文章

MongoDB数据库文件损坏恢复数据全过程

一.故障描述 客户设备环境为一台操作系统为Windows Server 2008的服务器,部署MongoDB数据库.由于业务需要,客户在未关闭MongoDB数据库服务的情况下,对数据库文件进行了拷贝.将数据库文件拷贝到其他分区后,客户对原数据库分区进行了格式化操作,后将数据库文件拷回原分区,重新启动MongoDB服务,这时,客户发现服务无法启动.报错如下:图一: 二.故障检测 一般来说,在服务没有关闭的情况下,直接对MongoDB数据库文件进行拷贝,由于服务还在运行,会导致mongod.lock

数据库文件损坏修复

[场景]:对象浏览器中只有数据库名,数据库展不开,查看日志[由于数据库没有完全关闭,无法重新生成日志.],推测原因是服务器异常关停,造成数据库没有正常写完数据造成. [处理方法]:修复数据,舍弃异常数据.DBCC CHECKDB (mydb, REPAIR_ALLOW_DATA_LOSS),前提是要在单用户下 [完整的处理方法]: ALTER DATABASE [mydb] SET EMERGENCY --EMERGENCY状态下 数据库标记为 READ_ONLY,并禁用日志记录,并且仅限 sy

[课]9.2模拟数据库,表空间和数据文件损坏后的恢复操作

1环境准备 对数据库做一次全备份: 验证当前的备份文件: 2数据库损坏的恢复 2.1模拟数据库损坏 尝试重启数据库查看报错: 这里需要重点说明的是因为我们用的是CATLOG数据库作为目录数据库,所以即使控制文件丢失也不影响我们进行恢复. 现在我们查看一下告警文件的报错: 2.2进行数据库恢复 3表空间损坏的恢复 3.1模拟表空间损坏 查看当前库的表空间,现在我们就模拟TEST_MSSM和TEST_ASSM表空间损坏. 删除表空间文件: 重启数据库查看报错信息: 我们查询一下告警文件里的错误信息:

MySQL实例多库某张表数据文件损坏导致xxx库无法访问故障恢复

一.问题发现 命令行进入数据库实例手动给某张表进行alter操作,发现如下报错. mysql> use xx_xxx; No connection. Trying to reconnect... Connection id: 5 Current database: *** NONE *** Reading table information for completion of table and column names You can turn off this feature to get

简单记录一次REDO文件损坏报错 ORA-00333重做日志读取块出错

一.故障描述 首先是实例恢复需要用到的REDO文件损坏 二.解决方法 1.对于非当前REDO或者当前REDO但是无活动事务使用以下CLEAR命令: 用CLEAR命令重建该日志文件SQL>alter database clear logfile group 3: 如果是该日志组还没有归档,则需要用SQL>alter database clear unarchived logfile group 3: 因为是当前实例恢复需要用的REDO,且未归档,使用是CLEAR命令不行的. 2.没备份,有备份可

RAC环境下控制文件损坏重建过程

处理过程参考了: https://blogs.oracle.com/Database4CN/entry/%E5%A6%82%E4%BD%95%E9%87%8D%E5%BB%BArac%E7%9A%84%E6%8E%A7%E5%88%B6%E6%96%87%E4%BB%B6 问题现象: 现场有学校提报 登录PL/SQL连接数据库是报错“ORA-12541: TNS:无监听程序 ”:排查日志,发现 Tue Nov 25 14:46:58 2014 Thread 2 advanced to log s

案例:Oracle exp dmp文件损坏 通过CPFL工具抽取dmp中的数据表进行恢复

Oracle数据库逻辑导出exp的dmp文件损坏,通过非常规恢复抽取dmp文件中表的数据 在有些时候,exp的dmp文件因为某种原因损坏(比如磁盘异常,exp过程损坏等),导致imp导入无法继续,下面的处理方法(直接读取dmp文件)来对dmp文件进行抢救性恢复,最大程度减少数据丢失损失 1.创建exp dmp文件并使用dd破坏 SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> selec

Oracle dmp文件损坏恢复案例

前一段时间帮一个朋友的朋友恢复了一个损坏的dmp文件,大概100多个G,记录一下恢复过程并简单总结一下 一.描述 这个dmp文件是从一个Oracle 9i的数据库上exp出来的,在导入Oracle 11g版本的时候,可能会随机出现两类错误,如下 (1)dmp文件导入的时候,一直停留在某张表上不动,两三天都是这样,导入操作无法进行,如下 导入了                                                             0 行 . . 正在导入表    

数据文件损坏、丢失

数据文件损坏(非系统表空间,非undo表空间),数据库关掉了 把备份拷贝到指定路径 startup mount alter database rename file '+DATA/ora11g/datafile/***' to '+DATA/ora11g/datafile/***'; recover datafile 4;读归档,补数据 alter database open; 数据文件损坏(非系统表空间,非undo表空间),数据库在open时 alter tablespace users of