技术人生系列第十期·我和数据中心的故事·运维无小事之一次导致数据丢失的小变更

前言

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

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

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

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

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

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

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

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

……

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

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

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

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

本期分享主题：

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

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

案例分享的意义：

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

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

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

先思考一个问题：

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

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

看上去这么做无可厚非啊，有问题么？

这么做到底有没有问题呢？看完小y接下来分享的具体案例，您就明白了：）

如果觉得网页版太长读的不过瘾，我们还提供PDF版本的下载，如何获得电子版pdf以方便阅读，请点击文章最下方"阅读全文"申请， 填写个人信息后，我们后续将第一时间发送电子版的pdf到您的邮箱，前100名会优先获得前九期的PDF 版本分享。

如果觉得分享的案例还不错，麻烦亲们抬手转发一下,希望可以提醒和帮助到更多的客户。

更多Oracle数据库实战经验分享和风险提醒的首发，尽在"中亦安图"公众号！欢迎关注。

有什么技术难题也可以给小y发邮件， 邮箱是 51994106@qq.com ,或者加小y的 微信(shadow-huang-bj) ，只要小y有时间，一定会尽力为大家解决疑难问题。着急的问题可以直接拨打小y的电话， 137-010-26113 Part 1

问题来了

悲剧出现

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

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

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

2） 该归档日志被删除了

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

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

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

1.1 文件online

1.2 Recover 数据文件

1.3 查看报错信息

1.4 归档日志去哪了

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

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

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

Part 2

事故时如何发生的

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

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

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

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

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

Part 3

剧情重现

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

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

3.1 变更"成功"

3.2 真的成功了么？

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

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

3.3 数据文件强制offline

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

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

看上去这么做无可厚非啊，有问题么？

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

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

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

Part 4

还有救么？

怎么解决？

这种情况下，有办法把数据文件online起来么？（当然也可以用抽取软件直接抽取数据）

小y这么问，自然是有办法，而且方法很简单（不到5步）。

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

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

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

4.1 检查SCN

4.2 确定SCN

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

4.4 修改SCN

4.5 数据文件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还是数据丢失？答案是显而易见的。归档空间不够，这需要从空间规划来入手，不行就预留七天的空间。数据的安全比廉价的存储空间更重要