SQL Server 2008 / R2恢复模型

我们某些服务器上的几乎所有数据库都不需要完全恢复模型（我们不执行事务日志备份），默认应始终是创建数据库并指定简单恢复模型。

出于某些实际原因，经常使用SSMS创建许多数据库。但是，可能会出错，并且操作员会忘记指定简单恢复模型。几天后，由于三个或四个从未被截断的60GB日志文件而导致磁盘空间不足时，这会导致“意外”。

通过在model数据库上配置恢复模型，可以使简单恢复模型成为新数据库的默认设置。但是，是否建议这样做，如果我这样做，将来它会以任何方式咬我吗？

我在这里看到三个选项之一：

1）您可以使用模板化脚本来创建明确包含恢复模型的数据库。

2）您可以将model数据库设置为简单，而不必为此担心。

3）您可以希望每个人都记得，这就像您在做什么。（不建议）

我个人将排第二。这就是模型数据库的用途。

添加到@ Surfer513

4）基于策略的管理策略要么强制实施简单的恢复模型，要么至多让您知道​​何时没有数据库

尽管我赞成将模型设置为简单，但这不会阻止使用T-SQL命令并将其设置为其他命令。您可以使用策略评估恢复模型是否不简单，并选择让策略为您更改它。

这篇 MSSQLTip.com文章介绍的是“完整”检查，但是您可以轻松地检查“简单”检查。您还可以检查数据库是否也曾经进行过备份。

可以肯定的是，将数据库置于完整模式，但随后出现了日志增长问题。现在有一些选择：

• 对日志文件的最大大小进行限制。一旦达到此限制，这将影响操作。这样做的好处是可以防止磁盘空间不足而导致更大的问题。
• 创建一旦您的日志文件超过水印就触发的警报，然后对其进行管理。
• 计划日志收缩作业。混用日志会损害数据库的性能。我不建议这样做。

作为DBA，您应该使用有助于恢复的所有选项。这也取决于您与业务相关的SLA。

综上所述，我以简单模式管理一些数据库。这是因为SLA中概述了免责声明。企业决定不为日志文件的驱动器花钱（您可以骑马，但不能喝水）。企业管理备份，还原和灾难恢复。有一个灾难恢复，所损失的钱大于在额外磁盘空间上的损失。