MSSQL Server 10失控日志增长，100GB /周

检查数据库是否处于完全恢复模式。 如果是这样的话，你是否有工作要运行，以实际备份频繁运行的事务日志，以使其保持可pipe理的大小？

编辑：

由于增长受限，当文件已满时，数据库将停止处理事务，因为它无处login。 您需要理清文件增长的原因，而不是限制文件。

如果它是一个非常繁忙的（而且非常庞大的）数据库，则每周100GB的日志可能不会太离谱。 没有关于数据库大小，交易量，logging尺寸等的更多信息，这是我们难以判断的。

更重要的问题是：如果这个数据库是每晚备份的，为什么日志没有被修剪？ 通常， 每周不需要担心事务日志量。

背景信息：

1. 在正确configuration的MSSQL服务器上，事务日志与数据在物理上是分开的：它们不仅驻留在单独的卷上，而且还驻留在完全独立的RAIDarrays上。
2. 如果数据库（或存储数据库的物理卷）丢失，则可以从最近的备份中进行恢复，然后重播事务日志以恢复数据，直到发生故障。
3. 在最近的备份之前创build的任何事务日志条目都可以从LDF文件中删除 。 通常情况下，日志本身会在修剪之前得到备份。 如果保留了较旧的备份，则这保持恢复到可能在最近的备份之前的任意时间点的可能性。

所以，这里有一个更大的问题：如何备份这个SQL服务器，并且在每次备份的时候修剪事务日志？ 是否有夜间备份过程突然停止工作？

如果以前的pipe理员懒得使用正确的服务帐户 – 这种情况并不罕见 – 包括备份在内的很多事情在他/她的帐户被禁用并且内置的域pipe理员帐户密码被更改时可能会停止工作。

另外 – 数据和日志在c盘上没有业务。 在忙碌的数据库上对IO进行分区是性能的关键。

就像克里斯说的那样，当你的数据库被设置为完全恢复模式（几乎肯定是），你必须运行某种备份来截断事务日志。 如果不是，你会看到它不断增长。 如果您不关心该数据库的恢复窗口，则可以将恢复模式设置回基本。

另外，将它们移出C盘。 在该驱动器上运行将导致数据库崩溃并可能导致损坏

我将更改为模型数据库上从FULL到SIMPLE的恢复模型。

在我们的组织中，完全恢复模式是我们计划的一个有意的决定。 在模型数据库上设置SIMPLE可以消除日志文件填满驱动器的可能性，因为它没有定期备份。

哪个版本的MSSQL？ SQL Server 2008已经删除了截断日志文件的能力（并且这样做有非常好的，有效的原因），所以如果你的日志文件失控了，你需要重新启动它，并获得适当的维护计划，以确保它不会再发生。

这就是说，如果你不使用：

• 镜像
• 事务日志传送

那么没有真正的理由让你进入完全恢复模式。 如果将其切换为Simple，则会使日志文件不再增长。