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

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

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

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

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

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

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

怎么解决？

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

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

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

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

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

故障原因总结:

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