我应该在完整备份之前运行 DBCC checkdb 吗？还是之后？

Question

我们混合使用了 SQL 2000、2005 和 2008 服务器，并且我们总是在完整备份之前每晚运行 DBCC CHECKDB，因为理论上您希望在备份之前确保数据库处于良好状态。（显然，备份的完整验证只能通过测试还原来完成，但这是一个略有不同的主题。）

假设我无法将 DBCC 卸载到备份服务器或其他东西（这将是理想的），DBCC CHECKDB 后跟 FULL BACKUP 是最佳顺序吗？

我发现的唯一讨论这个问题的“最佳实践”文档是SAP 的 SQL Server 维护最佳实践从 2006 年起我在 TechNet 上发现：

理想情况下，在执行在线数据库备份之前，应该使用 DBCC CHECKDB 运行一致性检查。

这个建议正确吗？它对所有版本的 SQL 都正确吗？

（如果这有帮助，提出这个问题的部分动机是 DBCC 运行时间似乎每晚都有很大差异，因此我们不能依赖备份完成的确切时间，这使得安排磁带存档作业变得困难。此外，如果维护运行时间很长并且由于任何原因必须取消，我宁愿备份可靠地完成而不是 DBCC。）

Answer 1

您可能要考虑的另一件事是，如果您有另一台服务器（开发服务器或其他服务器）可用于测试恢复备份文件，您可能希望在该服务器上执行此操作。因此，请先恢复数据库，然后再执行 DBCC CHECKDB。这样，您不仅可以验证备份文件是否完好，还可以验证数据库是否完好，而不会影响生产。

我们每周测试将所有备份恢复到另一台服务器，然后在其上运行 CHECKDB。

Answer 2

这是我的看法...

就可恢复性而言，运行 CHECKDB 的具体时间并不重要，但它可能会帮助您确定备份是否良好。

假设你的数据库损坏了。

当您的预备份 DBCC CHECKDB 失败时，您就会知道您的后续备份可能没有用。

如果先运行备份，然后再运行 CHECKDB，那么您将无法确定备份是好是坏（损坏可能发生在备份和 CHECKDB 之间）。这对您来说重要吗？

我想说，只要您定期运行 CHECKDB，具体时间并不重要。正如您所说，定期测试恢复是无可替代的。

Answer 3

如果无法在维护窗口中安装完整的 DBCC CHECKDB，则可以添加带校验和到您的备份例程，并在不同时间执行完整的 CHECKDB（SQL 2005 及更高版本）。

请注意，BACKUP [...] WITH CHECKSUM 不会取代 DBCC CHECKDB。Paul Randal 有更多详细信息这里。

Answer 4

如果/当您确定数据损坏时，了解您的恢复策略也会很有帮助。如果您打算恢复到故障点，那么在备份之前运行 checkdb 可以节省您的时间并避免丢失数据。