Monthly Archives: February 2012

前一段时间给一个客户恢复了一个数据库。 事情其实已经过去一段时间了，而且整个过程无非是一个数据库的基于时间的不完全恢复，从技术角度讲，没有什么太多可以值得描述的，而且由于所有的操作都是在客户的主机上进行，因此没有留下任何的痕迹，因此这件事情很难写成一篇技术相关的文章，所以也就一直没有写出来。 今天打算简单描述一下这个问题，主要是受Eygle的影响，Eygle最近刚刚写完一本新书《数据安全警示录》，我在帮他进行一些文字上的检查工作。在这本书中，Eygle用他帮别人恢复数据库的案例来警示大家，希望大家能利用别人的失败教训来警醒我们自己。 虽然我的这个案例在技术上并没有太多值得描述的，但是这个案例本身却很有借鉴意义，在这里和大家分享一下。 我们接到客户的请求是周五的下午，据说客户的数据库在周四夜里DOWN机，随后负责维护的人员对数据库进行了恢复，但是数据库丢失了部分数据，客户对于恢复的程度不认可，于是找到了我们。 开始以为只是由于不完全恢复的RESETLOGS导致了少量的数据丢失，可能需要通过类似LOGMINER的方法来看看能否多恢复一些数据，但是到了现场进行了简单的沟通后，发现我们之前得到的信息非常的不准确。 客户的数据库在周四夜里11点左右DOWN机，随后负责维护的人员对数据库进行了恢复，但是数据库最终只恢复到了周四上午10点左右，客户对于这种程度的恢复当然是不认可的，以致于最终对于现场负责维护的技术人员的不信任，最终找到了我们。 而对于现场环境的检查后，发现了很多的问题。 数据库DOWN机的原因是由于当前日志损坏，由于数据库的日志每组只有一个，这个当前日志的损坏不但导致数据库的DOWN机，而且会造成数据的丢失。但是损失仅此而已，只是当前日志中少部分已经COMMIT但是还没有写到数据文件的数据。对于这种情况，最差的情况是丢失一个小时的数据，也就是说到上一个日志切换时刻数据都是正常的。而对于当前日志丢失的情况，完全没有必要也没有理由去执行全库的恢复，只要清除当前损坏的日志就可以打开数据库。执行全库的恢复说明维护人员根本不理解Oracle的备份恢复机制，只是发现数据库无法正常打开，就去盲目的还原并恢复数据库，导致更多的问题产生。 维护人员水平不高，因此备份策略的不严谨以及备份和恢复过程的混乱也是意料之内的事情。首先，Oracle的备份策略存在比较严重的问题，客户的环境中有存储备份的带库，这对于数据库备份而言，应该是更安全的保障，但是备份策略的设置不但没有提高备份的安全性，反而使得备份的可用性下降。 客户的数据库每周执行一次全库备份，每天进行一次增量的备份，此外每天要进行多次的归档日志的备份。除了全库备份一定存储在带库上之外，增量备份和归档日志的备份有可能存储在带库上，也有可能存储在磁盘上，且没有任何一个位置上的备份是齐备的。以这次的问题为例，进行数据库的恢复首先需要恢复4天前带库上的全备，然后需要应用3天前带库上的增量，2天前磁盘上的增量，1天前带库上的增量，以及带库和本地磁盘上最近一天的归档备份。这种备份策略导致的一个问题就是，如果磁盘或带库任意出现一点损坏，就会导致数据库无法完全恢复。带库设备本来可以增加备份的可靠性，但是这种备份策略的设置使得备份的安全性和可靠性被降到最低。此外这种备份的存储和恢复也会给备份恢复的性能带来很大的影响。 除了备份策略的问题之外，操作过程也存在非常严重的问题。其中一点就是，数据库恢复过程的RMAN输出日志被删除。由于缺少当时恢复过程的日志，无法确定维护人员当时具体执行的操作是什么，所有的信息只能来自当事人的口述，本来口述这个方式就不靠谱，何况还是一个概念本身就不很清晰的人，而且问题产生的后果已经比较严重，很难说他在描述的过程中是否为自己开脱。总之，按照当事人的描述，恢复步骤应该是没有问题的，但是恢复后数据库中的数据只到早上10点左右，缺少了最后一天12个小时的数据。 最后维护人员还犯了一个更加严重的错误，第一次在进行数据库恢复的过程中，有一些带库上的归档日志文件被恢复到本地磁盘上。在数据库恢复完成后，出于空间的考虑，所有硬盘上恢复出来的归档日志被删除。但是由于删除的时候没有进行限定，删除操作删除了数据库硬盘上所有的归档，不仅包括恢复过程中从带库恢复到硬盘上的，还包括最新的几个还没有进行过备份的归档文件。这个删除的操作最终导致了数据库再次进行恢复时，丢失了最后两个小时的数据。 可以看到，原本一个只是损失几分钟数据，造成半个小时左右停机时间的故障，由于维护人员的错误，导致问题一步步放大，最终造成了损失2个小时左右的数据，且数据库停机一天半以上的重大事故。