我有我公司最近接手的一个项目的数据库的 .bak 文件。
我可以恢复几个 .bak 文件，但是最重要的一个文件失败了。
当它失败时，我只会收到一个一般错误，并要求检查日志。
这是发生的错误：消息 SQL Server 断言：文件：，行=1443 失败断言 = 'pFile'。此错误可能与时间有关。如果重新运行该语句后错误仍然存在，请使用 DBCC CHECKDB 检查数据库的结构完整性，或重新启动服务器以确保内存数据结构未损坏。
我不知道如何在 *.bak 文件上运行 DBCC CHECKDB。
任何帮助都将不胜感激。虽然我有 SQL 开发经验，但我绝对不是 DBA。所以假设我是个白痴。:)
谢谢！
答案1
出现该断言的原因是，恢复代码从备份中读取了一个页面，但该页面已损坏，并且页眉中标记的文件 ID 在正在恢复的数据库中不存在。它从名为 bckioreq.cpp 的代码文件触发（我在 MS 时拥有所有这些内容）。
运行 DBCC CHECKDB 的消息是通用消息，不适用于这种情况。
我认为您正在恢复完整数据库备份，然后是一系列其他差异和/或日志备份？您正在恢复 2005 年的备份，但是您正在恢复更早的备份吗？
这就是代码中所谓的零售断言 - 绝对没有办法绕过它 - 一旦代码遇到它，断言就会触发，恢复就会失败。有一个 Connect 项目可以使它更好，但它在 2008 年也没有修复。
这是否发生在您正在恢复的完整备份或后续差异备份和/或日志备份之一上？如果是完整备份，您无能为力 - 该备份已完蛋。如果是后续备份之一，您可以恢复到该备份之前的所有内容（但不包括该备份）。
恐怕这基本上就是你的答案。
那么，这是怎么发生的呢？（反问）可能是备份的数据库已损坏，或者 I/O 子系统损坏了备份。您可以采取一些措施来帮助防止这种情况发生 - 在数据库中启用页面校验和，并在备份中使用 WITH CHECKSUM 选项。这会增加一些检查以确保备份的内容没有损坏。您还可以通过各种方式验证您的备份 - 查看我对此的博客文章：验证备份的重要性。
希望这可以帮助！