数据库数据恢复—SqlServer数据库表结构损坏的数据恢复案例
SQL Server数据库故障&分析&恢复方案:
SQL Server数据库的数据无法被读取。
经过数据库数据恢复工程师的初步检测,发现SQL Server数据库文件无法被读取的原因是底层File Record被截断为0,无法找到文件开头,而且数据表结构也已经损坏。镜像文件的前几十M和中间一部分空间被覆盖,系统表损坏,所以无法读取。
日志中的操作记录:
北亚企安数据恢复—SqlServer数据恢复
由于系统表损坏,大量数据表的结构无法确定,只能靠仅有线索和数据恢复工程师的技术&经验来恢复数据库数据。
经过北亚企安数据恢复工程师团队的会诊,最终敲定针对该数据库的数据恢复方案:
1、备份数据。对丢失数据的硬盘做全盘镜像备份,以确保数据的安全性。
2、分析备份文件中原数据库,从原数据库中寻找数据表的结构。
3、从日志中提取一部分数据表的结构。
4、从日志中和残留数据中提取完好的数据。
5、根据日志恢复对应的数据,并检查数据的正确性。
6、核对数据没问题后恢复所有数据。
SQL Server数据库数据恢复过程:
1、将故障数据库所涉及到的硬盘标记后从服务器上取下,移交给硬件工程师检测是否存在物理故障。经过检测没有发现有磁盘存在物理故障。将每块硬盘以只读方式做扇区级全盘镜像。镜像完成后将所有硬盘按照原样还原到原服务器中。
备份硬盘数据:
北亚企安数据恢复—SqlServer数据恢复
2、打开镜像文件,分析硬盘底层数据,发现硬盘底层残留着许多SQL Server数据库的日志和备份文件。经过查看和分析,发现日志中有很多包括插入语句的数据库操作记录;备份文件中有建表语句和一部分旧数据。
北亚企安数据恢复工程师编写了一个提取数据库相关数据的小程序,扫描所有存在的数据库残留并提取所有数据。
3、分析扫描到的所有日志文件,发现日志文件中的数据记录有着固定的开头和结尾,其中每条数据都在固定的位置上有自己的OBJECT_ID号,在接下来的扫描文件中,继续搜寻有同样OBJECT_ID的数据记录,发现结构相同,就可以确定这是完好的数据,并进行提取。
分析扫描到的备份文件,发现很多建表语句,根据这些语句可以获取到一部分表结构。针对剩余的表结构,由于截断为0的部分刚好在系统表,没有办法提取表结构,只能通过从日志中提取的数据来推理表结构和数据类型。
4、根据前面的分析,北亚企安数据恢复工程师编写程序从备份文件中提取建表语句,根据建表语句分析出表结构与各种数据类型。
5、在残留的系统表中寻找22H、07H、05H表,根据这些建立表与OBJECT_ID的对应关系。北亚企安数据恢复工程师编写程序提取日志中的记录,根据OBJECT_ID将数据和表进行对应,并插入到新表中。
6、经过验证,用户方确认恢复出来的数据完整有效,认可数据恢复结果。
北亚企安数据恢复—SqlServer数据恢复
系统架构师:数据库的故障与恢复
数据库的故障可用事务的故障来表示,主要分为四类:
- 事务故障。事务在运行过程中由于种种原因,如输入数据的错误、运算溢出、违反了某些完整性限制、某些应用程序的错误,以及并发事务发生死锁等,使事务未运行至正常终止点就被撤销,这种情况称为“事务故障”。
- 系统故障。系统故障是指系统在运行过程中,由于某种原因(如操作系统或数据库管理系统代码错误、操作员操作失误、特定类型的硬件错误(如 CPU 故障)、突然停电等造成系统停止运行),致使事务在执行过程中以非正常方式终止,这时内存中的信息丢失,但存储在外存储设备上的数据不会受影响。
- 介质故障。系统在运行过程中,由于某种硬件故障,如磁盘损坏、磁头碰撞或由于操作系统的某种潜在的错误、瞬时强磁场干扰,使存储在外存上的数据部分损失或全部损失,称为“介质故障”。这类故障比前两类故障的可能性虽然小得多,但破坏性却最大。
- 计算机病毒。计算机病毒是一种人为破坏计算机正常工作的特殊程序。通过读写染有病毒的计算机系统中的程序与数据,这些病毒可以迅速繁殖和传播,危害计算机系统和数据库。目前大多数病毒是在 PC 和其兼容机上传播的。有的病毒一侵入系统就马上摧毁系统,有的病毒有较长的潜伏期,有的病毒则只在特定的日期发生破坏作用,有的病毒感染系统所有的程序和数据,有的只影响特定的程序和数据。在数据库系统中,恢复的基本含义就是恢复数据库本身。也就是说,在发生某种故障使数据库当前的状态已经不再正确时,把数据库恢复到已知为正确的某一状态。目前数据库系统中最常用的恢复方法是转储和登记日志文件,可根据故障的不同类型,采用不同的恢复策略。
事务故障的恢复。事务故障是指事务未运行至正常终止点前被撤销,这时恢复的系统应对此事务做撤销处理。事务故障的恢复是由系统自动完成的,不需要用户干预,步骤如下:
- 反向扫描文件日志,查找该事务的更新操作。
- 对该事务的更新操作执行逆操作。
- 继续反向扫描日志文件,查找该事务的其他更新操作,并做同样处理。
- 如此处理下去,直至读到此事务的开始标记,事务故障恢复完成。
系统故障的恢复。系统故障发生时,造成数据库不一致状态的原因有两个:一是由于一些未完成事务对数据库的更新已写入数据库;二是由于一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库。系统故障的恢复是在重新启动时自动完成的,不需要用户干预,步骤如下:
- 正向扫描日志文件,找出在故障发生前已经提交的事务,将其事务标识记入重做(Redo)队列。同时找出故障发生时尚未完成的事务,将其事务标识记入撤销(Undo)队列。
- 对撤销队列中的各个事务进行撤销处理:反向扫描日志文件,对每个 Undo 事务的更新操作执行逆操作。对重做队列中的各个事务进行重做处理:正向扫描日志文件,对每个 Redo 事务重新执行日志文件登记的操作。
- 介质故障与病毒破坏的恢复。在发生介质故障和遭病毒破坏时,磁盘上的物理数据库被破坏,这时的恢复操作可分为三步:
- 装入最新的数据库后备副本,使数据库恢复到最近一次转储时的一致性状态。
- 从故障点开始反向读日志文件,找出已提交事务标识将其记入重做队列。
- 从起始点开始正向阅读日志文件,根据重做队列中的记录,重做所有已完成事务,将数据库恢复至故障前某一时刻的一致状态。
具有检查点的恢复技术。检查点记录的内容可包括:
建立检查点时刻所有正在执行的事务清单。
这些事务最近一个日志记录的地址。采用检查点的恢复步骤如下:
- 从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录。
- 由该检查点记录得到检查点建立时所有正在执行的事务清单队列A。建立重做队列R和撤销队列U,把 A 队列放入 U 队列中,R 队列为空。
- 从检查点开始正向扫描日志文件,若有新开始的事务 T1,则把 T1 放入 U 队列,若有提交的事务 T2,则把T2从U队列移到R队列,直至日志文件结束。
- 对 U 队列的每个事务执行 Undo 操作,对 R 队列的每个事务执行 Redo 操作。
DBA 要做的基本操作是:
- 重装最近转储的后援副本。
- 运行日志文件,执行系统提供的恢复命令。
数据库安全和恢复是数据库系统正常运行的保证。大型数据库管理系统一般都提供了实现安全机制的保证,即由系统提供了相应的功能,但小型的数据库管理系统并非都具有相应功能,因此有时需要人工的辅助措施,用以保证数据库的安全和恢复。
本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com
文章为作者独立观点不代本网立场,未经允许不得转载。