一次导致数据丢失的小变更

前言

不知不觉,技术人生系列·我和数据中心的故事来到了第十期,小y又和大家见面了!

前期我们分享了不少Oracle数据库故障和优化的实战案例,有朋友问,小y是否可以分享一些无备份时数据恢复方面的实战案例呢?

答案自然是——当然可以了。小y从来就不是一个藏着掖着的人嘛 ^_^

这些年,小y所在的Oracle服务团队,该遇到的和不该遇到的问题,基本都碰到了。

所以在无备份的数据恢复这方面做的案例还是很多的,有时一周甚至要做三四个这样的CASE,问题类型不尽相同,例如:

>> 某电信运营商文件系统满,维护人员清理了在线日志文件导致数据库无法启动…

>> 某电信IDC机房掉电,Oracle数据库损坏无法启动…

>> 某基金客户将数据库用户误删除drop user xx cascade….

……

小y从内心觉得,“没有备份的数据恢复案例”确实不太好拿出来分享,毕竟这样的故障对客户而言是不光彩的事情,如果敏感信息没有被处理的很干净,就怕客户对号入座,给自己找麻烦,所以一开始也就没有分享类似案例的念头了。

但是转念一想,如果可以把共性的风险提炼出来,不仅可以从技术层面从给大家做一个提醒,还可以从如何完善数据库运维体系的角度给出建议,那么这种案例分享就变得有意义了!

这里补充一点,有朋友可能会好奇的问,”像接到这种CASE,客户已经绝望,你们可以狮子大开口,开个高价,一定不少赚吧?!”

实际上,很多情况下,按照中亦科技的风格和理念,我们是服务于企业客户的,是要做口碑的,从和客户(或潜在客户)长远合作的角度来考虑,这种CASE我们大部分都是给客户免费做的(没让你失望吧)。要收费也是看损坏程度和人力投入,我们报的绝对是良心价(低到不好意思说),毕竟客户都已经很难过了……如果趁机狠狠的宰上一笔,那么也就是一锤子买卖,后续基本不会再有长久合作了,这是不符合我们的服务理念的。

本期分享主题:

分享一个Oracle变更导致数据丢失的案例,然后启发大家思考这样一个问题,

你的Oracle 数据库运维体系真的完善么?

小y今天就为大家奉献这么一个真实的案例。分享的最后,除了进行技术风险的提示,我们还将就如何建设科学运维体系的话题给出中亦科技的观点,希望能对大家有所帮助。

案例分享的意义:

小y发现一个问题,就是别人不管再怎么做风险提醒,很多客户还是会犯一样的错误!

即使他知道别人已经遇到过的这个问题!

为什么他知道这个问题、这种风险,但是他还是犯了同样的错误呢?因为他没有切身之痛!如果只是在看别人的笑话,没有行动起来,从运维体系的角度做出整改,那么后续就很可能会出现类似的问题。小y希望读者朋友,可以领会小y每一次分享的精髓和良苦用心,做到由点带面,从运维体系的角度出发进行整改和预防,这样一来也就没有浪费小y的一片苦心。

先思考一个问题:

你的系统中是否还存在着类似下面这样一个处理逻辑的脚本呢?

为了避免归档日志来不及备份到磁带从而将归档文件系统撑满继而导致数据库hang,很多客户的系统中往往存在这样的一个脚本,当归档文件系统使用率达到60%的时候,启动脚本备份日志到带库,当归档日志使用率超过90%,删除归档日志,并且发出报警信息,提示归档日志被删除,需要尽快进行一次全备!

看上去这么做无可厚非啊,有问题么?

这么做到底有没有问题呢?看完小y接下来分享的具体案例,您就明白了:)

Part 1

问题来了

悲剧出现

一个潜在的客户发现访问256号文件上的数据时报错,256号文件无法被访问。

进一步检查因为文件被offline,需要做recover。

并且该文件无法再online起来,原因是缺少归档日志,无法做recover。

于是向小y求救。小y心想,无非是两种情况

1)  是不是归档日志备份到磁带上了

2)  该归档日志被删除了

如果是第一种情况,那么就简单了,只需要从磁带上恢复回来即可!

如果是第二种情况,那就糟糕了,可能要丢数据了!

没关系,我们不惹事,事来了我们也不怕。

我们先来看下客户online数据文件的操作过程:

1.1 文件online

256号文件的online操作,显然oracle会提示该文件需要做介质恢复即media recovery。因为文件在offline的时候(不管什么原因)不会把该文件所对应的脏块刷到磁盘中。

1.2 Recover 数据文件

于是客户做了recover datafile 256的操作,并输入AUTO,但是数据库提示找不到序列号为14389的日志文件

1.3 查看报错信息

操作系统上检查,该日志文件也不存在

1.4 归档日志去哪了

是不是备份到磁带上以后,在文件系统上被删除了呢?

检查rman的备份情况,发现节点1所需要的归档日志根本没有任何备份的记录!

这下悲催了!256号文件online所需要的的归档日志已经被删除!数据可能要丢失了

Part 2

事故时如何发生的

一个小变更怎么会导致这样的状况

经了解,这是一个IBM AIX上的10g RAC环境,数据文件采用裸设备。

客户最近刚为RAC做了一次表空间加数据文件的“小”变更!

那么文件被offline,以及归档日志找不到了,这两个问题的出现和这次变更有直接的关系么?给表空间加个数据文件,这样的变更也会导致数据丢失么?

也许你会觉得不可思议,不过小y基本已经猜到了过程。不同的地方总在上演着类似的悲剧。

到这里,建议读者朋友们可以先停一下,思考一下变更和这两个问题的关联!以及思考一下,如果是你,你接下来会协助客户怎么继续处理呢?

Part 3

剧情重现

为什么文件被offline&归档日志没了?

其实很简单,我们直接来看变更过程和问题出现的整个过程:

3.1 变更“成功”

1月4日11:50分左右,客户发起了变更。在RAC第二个节点为某个表空间添加了两个数据文件,并且添加成功。Alert日志显示Completed。变更“成功”

3.2 真的成功了么?

但是变更真的成功了么?变更做的利索么?

15:07分,节点1 在做checkpoint的时候,需要更新每个数据文件头的SCN号,但是由于新加的裸设备的操作系统权限不对,出现IO报错。显然,这是一个典型的RAC忘记修改一个节点权限的问题。这么多ORA-报错,如果这个时候发现并处理,那么一切还来得及!只是..没有可是了…

3.3 数据文件强制offline

15:07分,节点1由于裸设备的权限问题,checkpoint无法写文件头的SCN,因此新加入的两个数据文件被强制offline. 这么多ORA-报错,如果这个时候发现并处理,那么一切还来得及!只是..没有可是了…

3.4 发现问题

过了N个小时,当节点1访问这两个文件中的数据开始报错时,客户开始意识到问题的严重性了!从视图v$recover_file中可以看到,file_id为256和257的两个文件处于offline状态。

发现裸设备权限忘记修改的问题后,客户修改了节点1的裸设备的权限并且执行alter database datafile ‘/dev/xxx’  online数据文件时,提示需要做recover。

检查发现节点1文件被offline期间的的归档日志在文件系统已经被删除,rman还没来得及备份,再也无法恢复!

那么是什么原因导致归档日志被删除了呢?

还记得我们在文章一开始“前言”部分的下面这段话么?

你的系统中是否还存在着类似下面这样一个处理逻辑的脚本呢?

为了避免归档日志来不及备份到磁带从而将归档文件系统撑满继而导致数据库hang,很多客户的系统中往往存在这样的一个脚本,当归档文件系统使用率达到60%的时候,启动脚本备份日志到带库,当归档日志使用率超过90%,删除归档日志,并且发出报警信息,提示归档日志被删除,需要尽快进行一次全备!

看上去这么做无可厚非啊,有问题么?

这么做到底有没有问题呢?

没错,客户的系统中就存在着这么一个脚本!

由于备份到磁带不正常,导致归档日志文件系统使用率达到阀值,继而触发了脚本删除归档日志的操作!再加上变更时忘记修改一个节点裸设备权限的“巧合”,导致了悲剧的发生!

到这里,你是否还觉得为了避免数据库hang而删除归档日志,事后再发起全备的做法是一个安全的做法呢?答案显然是否定的!小y相信,90%以上的DBA在删除归档日志的时候是不会去查看v$recover_file中是否存在需要恢复的文件的!

Part 4

还有救么?

怎么解决?

这种情况下,有办法把数据文件online起来么?(当然也可以用抽取软件直接抽取数据)

小y这么问,自然是有办法,而且方法很简单(不到5步)。

用bbed将被offline文件的文件头的SCN改到和其他数据文件SCN一致即可,做起来也就几分钟,大家下来不防可以自己试一下。需要说明的是,这不过是一种骗过数据库一致性检测的方法,丢失了日志文件,数据丢失是不可避免的!

使用bbed修改数据文件头SCN时,唯一要小心的是修改时注意不同平台字节序的问题,linux平台是小字节序,高低位是相反的。

这里小y以自己环境的19号文件被offline后并且online需要的归档日志已经被删除的情况为例,来说明处理的过程。

4.1 检查SCN

检查v$datafile_header, 19号文件状态是offline,SCN和其他文件不一样

丢失日志的情况下,要想把文件online起来,只能骗过数据库,我们只要把19号数据文件的文件头上的SCN改成和其他文件比如17/18号文件一样就可以。

4.2 确定SCN

SCN号存在每个文件文件头(块号是1)的kcvfhckp.kcvcpscn这个结构当中,蓝色代表输入的命令,如下所示,红色部分即offset 484往后的4个字节表示SCNBASE,用16进制表示,我们将其用计算器转变为 10进制后,得到的数就是上图v$datafile_header的SCN。

4.3 注意字节存放高低位顺序

下图采用dump命令显示的的SCN号是 a883d301(见下划线)和上图中的

刚好是按照字节高低位相反的。

4.4 修改SCN

采用modify命令将19号文件的文件头上的SCN改成和其他文件比如17/18号文件一样,并重新计算校验值,最后verify确认BLOCK没检出异常就改完SCN了。

再次检查v$datafile_header,可以看到已经将19号文件已经被我们改成和其他文件SCN一样。

4.5 数据文件online

recover datafile后online起来,修复完成

Part 5

这是重点

故障原因总结:

本次案例中,为Oracle RAC表空间添加数据文件的一个变更,由于在一个节点忘记修改权限,导致数据文件被offline,后来归档日志由于文件系统使用率的原因,被脚本自动删除,从而导致了数据丢失的悲剧。通过bbed可以在没有日志文件的情况下把文件online起来,但是数据丢失是不可避免的!

中亦科技关于建设数据库科学运维体系的建议:

相信大家有一个共识,那就是“变更是导致故障的重灾区”。

运维无小事,变更无大小。

小的变更,往往因为熟练、轻视而没有充分准备详细的变更步骤。凭经验做事,加上熬夜疲惫、精神松懈等原因,很容易遗漏一些小的细节而导致大祸。

确实是这样的。

变更由人来操作(不可能用自动化运维手段来实现全部变更),是人就一定会有犯错的几率,即使是双人复核,也不能完全避免,而且真正长期做到变更双人复核的客户,绝对是少数。

那么,建设一套科学的运维体系就显得尤为重要了!

科学的体系下可以减少问题出现的概率。

以运维中的变更环节来举例,从方法论上来说,小y建议:

1、  梳理所有的变更

2、  梳理所有变更的风险点

3、  针对每个风险点,缕出对应的可行性解决方案

4、  解决方案从原则上说,是需要独立于现场实施人员的

具体到今天所分享的这个案例,小y认为有很多值得改进的地方:

1、  对于采用裸设备的RAC环境,缺少对于每个节点数据文件在OS上权限的监控

如果有这样的一个监控点,很快就可以发现节点1忘记修改权限,那么也就不会被offline了,也就不会出现由于数据丢失引发的故障了

2、  缺少对v$recover_file的监控

如果有这样的一个监控点,很快就可以发现文件被offline的情况,及时online起来就可以解决。另外,Online这个动作是否可以做成自动化呢?

3、  缺少对alert日志ORA-错误的监控或及时处理的机制

监控点的级别设置是否准确呢?同样是ORA-错误,预警则很容易被忽略;而严重则会发送短信通知。例如,小y有些同事在数据中心,每天需要轮着值班,对着监控的告警,逐条确认和分析、处理,以确保不被遗漏,从而保障业务的连续性。

4、  缺少对备份的监控或(和)及时处理机制

如果发现备份不成功的问题,例如备份作业太多导致排队,那么可以通过错峰、增加带机等形式,也就不会出现归档日志超过阀值得情况了。

5、  系统中无论如何也不应该存在删除归档日志的脚本

不删除怎么办呢?数据库会hang啊?你是接受数据库hang还是数据丢失?答案是显而易见的。归档空间不够,这需要从空间规划来入手,不行就预留七天的空间。数据的安全比廉价的存储空间更重要

运维是一门科学,你不可能遇到所有的问题,所以就需要一个科学的运维体系来减少问题出现的概率!也欢迎大家和小y就如何构建科学的运维体系进行讨论。

时间: 2024-10-06 13:16:42

一次导致数据丢失的小变更的相关文章

SPComm的一点小诀窍 spcomm的问题导致数据丢失 0x11与0x13错误

最近几天完成了BiasDAC的程序编写.调试的过程还算比较顺利,除了几个有点bt的小问题.其中一个困扰了我两三天的时间,今天上午终于将其解决. 由于BiasDAC是用RS232 Serial Port通信的,延用之前的程序,使用了Delphi的SPComm控件.在之前的使用中,SPComm控件一直工作正常,使用的是一般的string进行消息的传递. 而BiasDAC由于通信协议的限制,消息的发送使用的是hex方式,会用到从0x00到0xFF所有的这些字符.在调试中发现,发送0x11和0x13之后

一次惨痛的Ucloud云主机磁盘扩容操作导致数据丢失的经历

故障描述: 线上申请了一台Ucloud云主机用于搭建Zabbix监控平台,最近这台云主机的数据盘已经达到60G,决定将数据盘从80G扩容到200G,按照Ucloud官方文档http://docs.ucloud.cn/uhost/scaleup.html 的描述进行操作,umount /dev/vdb1后,再执行e2fsck -f /dev/vdb后抱如下错误 这种错误太多了,于是我按Contrl+C取消掉了,Ucloud技术支持那边给的建议是e2fsck -fy /dev/vdb,然后不再抱这种

hyper-v虚拟化未知原因故障导致数据丢失解决过程

简介: 由于MD3200存储中虚拟机的数据文件丢失,导致整个Hyper-V服务瘫痪,虚拟机无法使用,故障环境为Windows Server 2012服务器,系统中部署了Hyper-V虚拟机环境,虚拟机的硬盘文件和配置文件放在朝阳区某托管中心托管的DELL MD3200存储中(注:硬盘600G4,4T1).MD3200存储是由4块600G硬盘组成的阵列,用作存储虚拟机的数据文件.单块4T硬盘用作虚拟机数据文件的备份. 故障: 由于MD3200存储中虚拟机的数据文件丢失,导致整个Hyper-V服务瘫

气候变化会导致人类变小?科学家这样证实这个道理

科学家发现,目前的全球变暖趋势可能对哺乳动物的体型产生影响,甚至可能使人类变得更矮.科学家宣称已经找到证据:近5000万年前全球变暖就曾让世界上最早的马个头变小. 美国有研究人员指出,约在5300万年前,地球也经历了一段升温,在2万年间,全球气温上升了6℃.他们在对美国怀俄明州毕葛红盆地沉积岩中的哺乳动物化石进行调查时,发现利用臼齿尺寸作为评估体型的指标的话,那段时期那里的鹿和类似于狐猴的小型灵长类等哺乳动物,体型都变小了.而始祖马在这段时期也又一次"缩水",体型再次减小了约22%.研

直接拔出U盘会导致数据丢失吗

用过U盘的朋友们都会碰到这样的情况,想拔下U盘时,点击右下方的“安全删除硬件”的图标,都会弹出一个对话框,“现在无法停止‘通用卷”设备,请稍后再停止该设备”.有的朋友怕直接拔出U盘会不会导致数据的丢失,实际上这个时候并没有打开U盘中的文件,U盘也是正常的,但为什么会出现这个问题呢,直接拔出U盘里面的数据会不会丢失呢,下面就给大家讲解如何解决这种情况和避免直接拔出U盘时数据的丢失. 1.打开[我的电脑],选择你的U盘盘符,右击选择[属性],这时会弹出[可移动磁盘属性]窗口,然后切换到[硬件]标签.

raid-6磁盘阵列损坏导致数据丢失的恢复过程(图文教程)

一.故障描述机房突然断电导致整个存储瘫痪,加电后存储依然无法使用.经过用户方工程师诊断后认为是断电导致存储阵列损坏.整个存储是由12块日立硬盘(3T SAS硬盘)组成的RAID-6磁盘阵列,被分成一个卷,分配给几台Vmware的ESXI主机做共享存储.整个卷中存放了大量的Windows虚拟机,虚拟机基本都是模板创建的,因此系统盘都统一为160G.数据盘大小不确定,并且数据盘都是精简模式. 二.备份数据将故障存储的所有磁盘和备份sss数据的目标磁盘连入到一台Windows Server 2008的

存储互斥失败导致数据丢失的数据恢复成功案例

数据恢复故障描述 需要恢复的数据是某公司的一个信息管理平台,客户使用了3台虚拟机为企业共享一台存储设备,供企业内部使用,存储了公司大量的重要数据文件.管理员在在正常工作时为该存储网络又连接了一台Windows2003服务器,结果这台存储突然无法使用了,管理员对存储进行故障排查时发现存储虚拟磁盘丢失,分区表丢失.重启该存储后故障依然没有解决.由于存储中的数据十分重要且没有备份,管理员不敢擅自进行尝试修复,只好通过数据恢复手段进行数据恢复.图片来源于网络,侵删 存储数据恢复分析 由于存储崩溃的原因并

移动硬盘因格式化导致数据丢失该怎么恢复?

移动硬盘是很多人必备的储存设备,很多用户遇到过在使用过程中移动硬盘无法格式化和移动硬盘格式化后造成数据丢失,带着这些问题,继续往下阅读. 对于移动硬盘现在大家用到的有很多,但是在硬盘出问题的时候,格式化是避免不了的,但如果移动硬盘无法格式化的话,我们要怎么办? 移动硬盘无法格式化的原因:1.排除是不是供电不足导致,这种情况的话也会出现无法格式化的问题,我们尝试换一台电脑,然后插入台式机的后置usb,或者换一台笔记本电脑看看是否解决:2.是否数据线的问题,尝试换根数据线改善移动硬盘的连接情况试试:

服务器raid5磁盘阵列不同故障导致数据丢失的数据恢复方法(案例)

服务器Raid 5阵列算法 Raid5阵列使用的算法通常被称为"异或运算",这是一个数学运算符.它应用于逻辑运算.异或的数学符号为"⊕",计算机符号为"xor".其运算法则为:a⊕b = (?a ∧ b) ∨ (a ∧?b).如果a.b两个值不相同,则异或结果为1.如果a.b两个值相同,异或结果为0.异或也叫半加运算,其运算法则相当于不带进位的二进制加法:二进制下用1表示真,0表示假,则异或的运算法则为:0⊕0=0,1⊕0=1,0⊕1=1,1⊕1