我们有SQL 2000,2005和2008服务器的组合，而且我们每晚都在完整备份之前每晚运行一次DBCC CHECKDB，理论上你要确保数据库在备份之前保持良好的状态。 （显然，备份的完整validation只能通过testing恢复完成，但这是一个稍微不同的话题。）
假设我不能将DBCC卸载到备份服务器或其他东西（这将是理想的），那么DBCC CHECKDB之后是FULL BACKUP是否是最好的序列呢？
我发现讨论这个唯一的“最佳实践”文档是从2006年开始在SAP网站上发现的SQL Server维护SAP最佳实践 ：
理想情况下，在执行联机数据库备份之前，应该运行使用DBCC CHECKDB的一致性检查。
这个build议是否正确？ 所有版本的SQL都正确吗？
（如果这有帮助，问这个动机的部分原因是DBCC运行时间似乎每晚都有相当的变化，所以我们不能完全依赖备份完成的时间，这使得我们的磁带归档工作很困难，而且，如果维护时间长，因为任何原因必须取消，我宁愿备份可靠地完成比DBCC。）
另一件你可能会考虑的事情是，如果你有另一台服务器（开发或其他），你可以使用它来testing恢复你的备份文件，你可能想在那里做。 所以RESTORE DATABASE和DBCC CHECKDB。 这样，你不仅validation你的备份文件是好的，而且你正在validation数据库是好的，而不影响生产。
我们testing每周将所有备份恢复到另一台服务器上，然后在其上运行CHECKDB。
这是我的…
在可恢复性方面，运行CHECKDB并不重要，但它可以帮助您确信备份是否正常。
说你的数据库损坏了。
当您的预备份DBCC CHECKDB失败时，您会知道您的后续备份可能不太好。
先运行备份，CHECKDB之后，你会非常不确定是否有好的或不好的备份（在备份和CHECKDB之间可能会发生损坏）。 这对你有影响吗？
我会说，只要你定期运行CHECKDB，什么时候没关系。 正如你所提到的那样，定期进行恢复testing是不可替代的。
如果您无法在维护窗口中安装完整的DBCC CHECKDB，则可以将WITH CHECKSUM添加到备份例程中，并在不同的时间（SQL 2005及更高版本）执行完整的CHECKDB。
请注意，WITH CHECKSUM的BACKUP并不会取代DBCC CHECKDB。 Paul Randal 在这里有更多的细节。
如果/当您确定数据损坏时，了解您的恢复策略也是有帮助的。 如果您打算恢复到某个故障点，那么在备份之前运行checkdb可以节省您的时间并丢失数据。