作者：冬眠2502917261 | 来源：互联网 | 2023-09-02 03:04
IT界都相信黄油定律，似乎事件的发展总是向着最坏的方向，涂有黄油的一面总是最先着地。实际上，黄油定律的根源出自另外一句名言，一个事故背后往往有七个错误。这是一个比较久远的案例了，有一天，一个朋友在qq上问我，他的一套数据库系统存储故障导致SYSTEM表空间和数据表空间有大量的坏块，现在无法启动了，该怎么办。我第一反应是问他有没有备份，回答是没有。当时我觉得这个事情比较麻烦了，弄不好需要通过dul导出数据。在沟通过程中我了解到他们这套系统是一套较为重要的二线核心系统，所以这类系统他们都搭了Dataguard，不过Dataguard你那边的服务器配置都很低，无法承载业务。既然有Dataguard那就比较简单了，不管那边能不能承载业务，只要数据都在就好办了。于是我建议他们用Dataguard的数据文件来恢复生产的数据库。他听从了我的建议，马上去找数据库维保厂商到场干活了。本来以为这是件十分简单的事情，没想到最后这个朋友成为了我的客户。第二天早上我查看QQ，发现5点多钟就有一堆留言，那个朋友没有我的手机号，所以只能通过QQ留言。通过QQ我了解到昨晚的数据恢复十分不顺利，问我能不能抓紧飞过去帮他们处置一下。到达现场后，我认真阅读了日志文件，真的让我有点啼笑皆非，所有数据库运维能够遇到的问题几乎都被他们遇到了。关于数据最终的拯救过程十分简单，这里就不细说了，我们来分析一下这个事故背后的错误。
从备库的ALERT LOG上我们看到主库因为故障，与备库的网络通讯中断，备库停止了数据恢复。随后运维人员用只读方式打开了数据库并关闭了
然后再次MOUNT方式启动数据库实例，并且备份了控制文件
上面的操作虽然有点莫名其妙，不过还算正常。后面的操作就不正常了，运维人员在重建控制文件：
这次SWITCHOVER是注定要失败的，因为这个数据库还没有完全恢复“END-OF-REDO"，这种灾难情况下要运气十分好才有可能能END-OF-REDO。于是开始做recover database
在recover的时候遇到了一个问题，找不到一个归档日志文件。而客户的说法是，他们的归档日志都是保留至少一周的，不可能找不到归档日志。随后运维人员没有去查找这个归档日志找不到的原因，而是多次重建了控制文件：
标注了部分数据文件处于OFFLINE DROP状态。不过当时运维人员并未深究其原因。而是直接把这些命令拷贝了下来执行了！！！！第一个不可饶恕的错误出现了。
执行了这些命令后，控制文件成功创建了，并且数据库也成功打开了。似乎一切都OK了。没想到，这个打开的数据库只是个样子货，大量的表无法访问，一访问就报错。于是老白就到了现场，用户的目的有两个，一个是把数据拯救出来，一个是分析这次问题的原因，为以后运维引以为戒。
其中有不少OFFLINE的文件，甚至有很多文件的checkpoint scn都是0。这让我十分诧异。于是我们往前翻看日志：
原来那个重建控制文件还不是第一个错误，真正的错误在20多天前就造就了。从日志可以看出，DBA把standby 文件管理方式设置为manual，然后手工删除了一些名为UNNAMExxxxx的文件。然后把这些文件rename为一个裸设备名。可能各位看客会有点晕了，这种神操作是干什么的呢？老白这种事见得多了，一眼就明白发生了什么。如果我们在主库创建新文件时，备库的裸设备不存在，这样在备库中就会生成一个UNNAMEDxxxxxx的文件，为了将这个文件重新迁移到裸设备上，DBA就做了上述操作。这种失误以前发生过多次，每次都是采用这种方式去解决的，好像每次都成功了。
采用这种方式处理数据文件缺少了一个步骤，就是执行alter database create datafile ... As '....';从而导致该数据文件一直处于未完成修改的状态，也就是说这条命令并没有正确结束。因此虽然这些裸设备都已经存在了，DATAGUARD一直未对此文件进行REDO APPLY。并且在DATAGUARD中查看这些文件的状态是RECOVER状态。实际上这些文件大多数是空文件，里面并无任何数据。这就能解释我们上面看到的情况了。由于DATAGUARD中的这些文件本身存在问题，导致这类文件处于非正常状态，由于这些文件最早的是1月份创建的，所以有些文件需要1月份以来的REDO LOG，有些需要4月7日以后的REDO LOG，那个1_87118.dbf就是1月份的归档日志，此时早就被清理了，当时已经无条件进行修复。
所以可以说是一个1月份的错误操作导致了半年后的一次严重事故。类似这样的案例可能很多运维人员都遇到过，可能很多人犯过类似的错误而不自知吧。
其实出现这种问题主要有两个原因，一个是很早的错误没有被发现，导致出现严重后果时出现不可估量的损失。第二个是遇到问题时缺乏可用的应急预案或者专家的指导，操作过程中错误频频，导致小故障变成大故障。
京公网安备 11010802041100号