一个完整的DBCC操作能否安全地卸载到另一个服务器上恢复的备份中？

Question

我们目前正朝着24/7/365的运营模式前进--因此，我正在研究我们的维护策略。

我在弄清楚DBCC时遇到了一个问题。我已经看到了许多资源报告，DBCC可以通过执行完全备份、在单独的SQL实例上还原备份以及在还原的副本上运行我们的CHECKDB来卸载。我还找到了一些资源，报告说，这是不安全的，因为边缘情况的情况。

如果不运行于生产数据库本身，那么运行CHECKDB是否安全？如果没有，在还原的副本上运行哪些部件是安全的？

Answer 1

Server专家保罗·兰德尔在他的文章CHECKDB从各个角度: VLDB的一致性检查选项中讨论了这个选项

使用一个单独的系统这个替代方案相对简单--恢复备份(您正在进行定期备份，对吗？)在另一个系统上并在还原的数据库上运行完整的DBCC。这将从生产系统中卸载一致性检查负担，并允许您检查备份是否有效。然而，这也有一些缺点：

• 您需要在备用系统上有足够的磁盘空间，以便能够将备份恢复到。如果生产数据库是几个TB，则需要在备用框中使用相同的几个TB。这相当于一笔不小的资金--初始资本投资加上持续的存储管理成本。(希望未来的版本能缓解这一问题--而在微软，我发明了一种机制，并为其申请专利，以便在备份中检查数据库的一致性，而不恢复数据库。)
• 如果一致性检查发现错误，则无法确定生产系统上的数据库是否已损坏。这可能是造成腐败的备用箱的问题。唯一确定的方法是对生产系统进行一致性检查。不过，这是一个很小的代价，因为大多数情况下，备用系统上的一致性检查是可以的，所以您知道在备份时生产数据库是干净的。

除了Paul提到的缺点之外，我不知道将一致性检查卸载到另一个系统时有什么问题。

我给出了一个问题的答案- 如何对服务器数据库备份文件进行完整性测试？，在这里我描述了我们在我的商店使用的过程。

在我的店里，我们有一个“play”服务器，我们用它来自动恢复我们认为“重要”的数据库的最新完整/差异。我们使用来启动一个bat文件，该文件有几个SQLCMD步骤。成功还原后，我们使用ALL_ERRORMSGS、NO_INFOMSGS运行完整的DBCC，并将结果输出到txt文件中。然后，我们将输出的txt文件发送到数据库组进行评估。这个过程测试两件事

• 我可以恢复备份吗？
• 备份结构完整的数据(DBCC)。

还有一点:腐败随时可能发生。在良好的DBCC CHECKDB或成功的备份之后，请立即尝试经常运行DBCC一致性检查。