0 sql-server-2008 sql-server corruption
前几个月的 SQL 盒已经崩溃。我们几乎已经恢复了一些工具并在其上顺利运行应用程序的数据库。但是当我当时尝试备份数据库时，它给出了如下错误，
传递给数据库“****”中的日志扫描的日志扫描编号 (3533468:412:0) 无效。此错误可能表示数据损坏或日志文件 (.ldf) 与数据文件 (.mdf) 不匹配。如果在复制期间发生此错误，请重新创建发布。否则，如果问题导致启动失败，请从备份中恢复。（Microsoft SQL Server，错误：9003）
有人会帮助我摆脱这种情况吗？
我什至尝试复制数据库，但我失败了。
提前致谢。
首先，为什么要使用这些工具而不是简单地从备份中恢复？我的猜测是，您没有备份，或者您没有足够新的备份以供使用。好的，我们稍后会处理。
与此同时，如果我处于你的位置，我会更新我的简历并在它上面撒上童话般的灰尘创建一个新的空数据库，然后开始将你所有的表、对象、用户和代码转移到新的数据库中（很多可以使用 Management Studio 中内置的向导或使用 Red Gate 的 SQL 比较 / SQL 数据比较等 3rd 方工具来完成此操作。完成后，您可以删除以某种方式设法运行的 Frankenstein 数据库（不确定“某些工具”是否值得称赞-我认为它们根本没有给您带来任何好处）。删除后，您可以重命名新数据库，一切都应该恢复正常。
虽然您可以使用诸如 之类的东西来修复当前数据库存在的任何问题DBCC CHECKDB ... WITH REPAIR_ALLOW_DATA_LOSS，但您收到的错误消息听起来比几个坏页面更令人发指。我会尽快从这些文件中取出您的数据。
接下来，我的意思是立即建立一个合理的备份和恢复策略。这并不意味着仅仅进行备份，而是进行备份并定期测试您是否可以恢复它们。这个问题与损坏或从崩溃的数据库中恢复无关，但那里的答案肯定详细说明了不同恢复模型的来龙去脉。通常，每晚或每周进行一次完整备份是不够的 - 您需要在两者之间进行差异备份或日志备份，以最大程度地减少服务器崩溃时数据丢失的可能性。正如我所说，仅仅进行备份是不够的 - 您需要验证您正在进行的备份是否可以在不同的硬件上恢复 - 您知道，如果您当前的硬件完全崩溃。
之后，联系这些“工具”的供应商并要求退款。这不是恢复数据的方法，他们显然对您的数据库做了一些无法恢复的事情，需要您进行更多的手动工作。很遗憾，您没有询问最初发生崩溃时该怎么做的问题，因为这里的人们肯定能够指导您采用更可靠的恢复方法。我发现使用这些工具的人通常会承诺完全恢复可疑或损坏的数据库，而不知道您可能对它做了什么，只是因为误导和/或恐慌的谷歌搜索而尝试使用它们。这些供应商擅长 SEO，但在实际兑现其牵强附会的承诺方面却不那么出色。