Help!我的数据库坏了,如何办?

来源:原创作者:编辑:admin2020-05-11 04:43

  数据库文件破坏能够是DBA面对到的最头疼的后果,在这篇文章中,我将向大年夜家说明一些不应当在数据库文件破坏时对数据库的一些操作,然后依据具体状况为大年夜家解说一些应当依据状况做出的操作,协助您处理此方面的后果。

  文件破坏照样比拟轻易肯定的,当有查询访问非正当的页数据时,查询就会以高严重性级别毛病而招致终止。备份和重建索引的作业会掉败。一些典范的毛病提醒以下:

  SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\Develop\Databases\Broken1.mdf'.

  Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.

  更恐怖的工作在于,假设平常没有按时的完整性检查,那么毛病能够存在小时、天、乃至上月,如许发生的后续后果就很难处理了。

  本文不会评论辩论数据库的质疑形状,因为说明为甚么会质疑,发明数据库质疑的启事、处理质疑的各种方法都可以拿一整篇文章或许书来评论辩论。

  不要惊慌(译者注:空话..)

  不要分别数据库

  不要重启数据库效劳器

  不要急切的运转REPAIR

  运转完整性检查

  最后,做一次深化的剖析,剖析发生后果的基本启事

  惊慌的结果常常是不理性的思考乃至不思考

  当效劳器申报数据文件破坏时,通俗来讲某些被破坏页确实存在在SQL数据文件中,所以,分别附加、备份恢复、重启数据库效劳这些技俩是不能清除毛病的

  同上,重启数据库效劳其实不能改良状况。

  比之分别附加,重启有能够会使状况更蹩脚,假设SQL在实施“重启恢复”(restart-recovery)的时分碰着了数据文件破坏,那么数据库就会被标注为质疑形状,将以后的修复任务变得越发艰苦。

  有些工程师能够会应用CheckDB 并应用 Allow Date Loss 选项并置信此举会处理很多后果,其真实很多时分,运转DBCC Allow Data Loss 其实不是引荐的方法,因为这不能修复一切毛病,而且能够会招致数据损掉。

  在很多状况下,此举是最后心甘宁愿的选择,只应在其他方法都没法处理的状况下应用,而不应当作为首选方法应用。

  为了肯定修双数据毛病的方法,或许究竟数据的哪局部出现了毛病,你应当运转 CheckDB 并应用 All_ErrorMsgs 选项。其余,No_Infomsgs 选项可以避免显示具体在哪页出现的毛病,这些对我们排错并没有太多协助。