Heim  >  Artikel  >  Datenbank  >  数据库备份与恢复 之七 应对由于备份损坏导致的还原错误

数据库备份与恢复 之七 应对由于备份损坏导致的还原错误

WBOY
WBOYOriginal
2016-06-07 15:23:551106Durchsuche

数据库管理员最大的梦魇,莫过于已经做了备份,但是在想恢复的时候,发现备份文件也是坏的。这将意味着数据库的丢失,后果非常可怕。发生这种情况的原因一般有3个: · 备份文件和数据库放在同一个(或一组)物理硬盘上。硬盘出故障,备份也保不

数据库管理员最大的梦魇,莫过于已经做了备份,但是在想恢复的时候,发现备份文件也是坏的。这将意味着数据库的丢失,后果非常可怕。发生这种情况的原因一般有3个:

·        备份文件和数据库放在同一个(或一组)物理硬盘上。硬盘出故障,备份也保不住。

·        备份介质损坏;或者做的是网络备份,数据在网络传输中发生了损坏。

·        数据库在做完整备份、文件备份或者文件组备份的时候,里面的内容就已经有了损坏。
SQL Server在做数据备份的时候为了节省时间,基本只是很简单地把数据页面拷贝下来,不会做一致性检查的。但是在恢复的时候,需要将数据库恢复(Recover)到事务一致的一个时间点。如果备份中的损坏妨碍了SQL Server的前滚后滚(Redo和Undo),恢复动作就会遇到错误。

无论何种情况,您都可以:

·        修复硬件错误并重新尝试还原操作。

·        忽略错误,继续还原操作,并在还原完成后修复数据库。

·        放弃还原操作,改用备用还原计划。

                在现实环境里,能够通过重试解决的问题还是比较少的。硬件错误往往会永久地损坏备份文件里的内容。在先前的SQLServer版本里,管理员可能不得不尝试去寻找更早的备份。这往往意味着有很多天的数据丢失,损失是比较大的。

SQL Server 数据库恢复有一个“忽略错误”的功能,在这种为难的时刻可以发挥很大的作用。

忽略错误继续执行操作

CONTINUE_AFTER_ERROR是恢复命令(RESTORE)里面的一个选项。它将使还原操作跳过错误继续进行,并还原SQL Server现在所能还原的所有内容。数据还原结束后,可以应用后续事务日志备份,将数据库恢复。如果日志恢复时遇到错误,SQLServer会在日志中报告,并且不让用户访问和这些事务有关的页面。数据库将在尽可能的情况下联机。所以大部分情况下,数据库整体还是能恢复出来,只是部分数据有可能会丢失。

数据丢失量取决于遇到的错误。例如,一般数据页中的错误只会引起该页进入可疑状态,但数据库恢复还会继续。有问题的页面编号将被写入磁盘并记录到suspect_pages表和错误日志中,提醒管理员在恢复结束后继续处理它们。如果不设置CONTINUE_AFTER_ERROR,SQL Server只要遇到一个页面有问题,整个恢复动作都会停止。

如果错误发生在一些比较关键的地方,比如某个数据文件的文件头信息,那么恢复还是有可能完全失败,数据库无法恢复。所以这个方法只供救急之用。不能保证每次使用的效果。使用WITHCONTINUE_AFTER_ERROR还原数据后,要检查错误日志以了解有关错误的详细信息。

基本的RESTORE语法为:

RESTORE DATABASE database_name

FROM backup_deviceWITH CONTINUE_AFTER_ERROR, [NORECOVERY ]

管理员可以在忽略错误继续执行的还原顺序结束时,使用DBCCCHECKDB修复数据库。要使CHECKDB在使用RESTORECONTINUE_AFTER_ERROR后以最大的一致性运行,建议在DBCC CHECKDB命令中使用WITH TABLOCK选项。在极个别情况下,可能没有足够的信息来修复数据库,CHECKDB也没办法修好数据库,数据丢失将不可避免。不是说,有了RESTORE CONTINUE_AFTER_ERROR,备份坏掉也没关系的。

建立备用(Standby)服务器

CONTINUE_AFTER_ERROR只不过是命令SQLServer跳过一切它能够跳过的错误,将所有还能读出来的数据恢复出来,从而最大程度地挽回数据。但是有些对数据一致性要求比较高的系统,比如银行账户系统,用户可不接受“部分”数据恢复。对他们来讲,数据不一致可能就意味着钱已经从一个账户转走,但是没有进入另一个账户,这是不可接受的。所以他们宁可将数据库恢复到昨天的状态,把今天所有的操作重做一遍。

对于这样的系统,在建立备份和选择恢复策略的时候,就要考虑到最坏的情况,预先想好方案,将损失降到最低。

事先预备一台备用机,将做好的备份使用LogShipping或者其他类似的机制在备用服务器上预先恢复好,是一个值得推荐的方法。这样做的好处有:

(1)比起物理镜像之类的技术,这种方案比较经济。备用服务器的硬件要求不高,只要硬盘足够大。

(2)虽然SQL Server提供了若干备份校验机制,但是确保备份完整可靠的唯一办法是真正地去恢复它。

(3)提前恢复备份,使得在真正灾难发生时,只需要恢复最后一个日志备份即可,而不需要在火烧眉毛的时候,去等那个漫长的完整备份恢复,可以大大节约灾难恢复时间。

(4)备用机上的数据库虽然不能修改,但是可以使用STANDBY参数将数据库恢复到只读模式。可以将一些报表查询工作转移到备用机上,减轻生产服务器的负担。

总之,数据安全非常重要,灾难恢复时间要求很短的数据库,如果没有镜像技术的保障,备用服务器是非常必要的。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn