在 SQL Server 2005 中在简单恢复和完全恢复之间切换的风险

Question

好的，所以我们在集群环境中的多个节点上有多个实例。其中之一是 JD Edwards 的东西，最近遇到了一个工作失败的问题，因为 tempdb 中没有空间来完成它。这项工作的代码多年来没有改变，但我意识到数据大小可能已经改变。

无论如何，在将 tempdb 设置为一些不会破坏该驱动器的 Autogrowth 后，我开始深入研究此安装。似乎有一些预定的作业正在从简单到完整来回切换恢复模式，并且出于某种原因应该在这些作业周围进行备份。我相信这是导致 T-Logs 备份在某些时候失败的原因，因此没有足够的空间让 tempdb 本身完成这些长期存在的 JDE 作业。

所以问题：

1. 我是否完全无知认为定期从简单到完整来回切换是一个坏主意？
2. 如果我是对的，这是一个坏主意，除了我已经描述的场景之外，还有什么其他场景可以用来向必须造成这种情况的 DBA 先生说明这一点？

TIA

Answer 1

在这种情况下，您应该首先调查可能丢失的数据量——即，您是否始终需要时间点恢复。

如果您确实需要能够恢复到一分钟，那么通过切换到简单恢复模型来破坏日志链是不可接受的。在切换到简单模式之前​​进行最终日志备份后，您将失去最多一分钟恢复的能力，并且在切换回 FULL 并执行额外的日志备份之前，您无法重新获得它。

如果您不需要能够恢复到一分钟，您可以研究使用 BULK LOGGED 恢复模型作为比切换到简单的更好的替代方法。但是请注意，在完成 BULK LOGGED 事务后，您仍然会有一个大型事务日志备份。

这是有关从 FULL 恢复模型切换到 BULK LOGGED 或 SIMPLE的有用 MSDN 参考。

从您的问题的上下文来看，听起来您的数据库日志文件与 tempdb 文件位于同一驱动器上。如果可以将您的 TempDb 文件隔离到另一个驱动器，这将有利于管理目的以及性能（取决于您的驱动器布局）。