缩小SQL Server事务日志

我目前必须处理已经失控的SQL Server事务日志。免责声明：我不是dba，这也不是我的专业领域，所以请多多包涵。

目前，我有一个用于500MB数据库的115GB事务日志文件，（很显然）一段时间以来，该日志文件的管理不善，使其处于此状态。

最重要的是在用尽之前回收此文件占用的磁盘空间！有人告诉我，增加驱动器的大小不是一种选择，即使是暂时的，并且根据过去的增长，我们需要尽快采取行动。

据我了解，最好的方法是使数据库处于完全恢复模式，但要定期备份日志文件，在一段时间内对其进行监视，并调整初始大小和增量以适应需要。很好

看到我们在午夜进行常规的完整数据库备份时，对我来说暂时将数据库置于“简单恢复模式”（在其中一种备份运行之后），收缩日志文件以收回（几乎所有）空间以及然后使用上述备份策略将其放回完全恢复中？

我的想法是，如果这段时间发生了一些事情，我们可以简单地还原完整备份，而无需使用日志。

更新

一些额外的细节，以回答一些答案和评论：

• 我们确实希望保留执行时间点还原的功能，因此数据库应保持完全恢复模式。

• t-log文件变得如此之大的原因是它从未被备份过。验证为log_reuse_wait_desc返回“ LOG_BACKUP”。

该数据库的事务日志包含自上次事务日志备份以来或上次从简单恢复模式切换以来的所有事务。执行以下命令以获得关于SQL Server为什么无法截断日志以及随后日志为何增长的明确答案。

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

如果要进行时间点恢复，则使数据库处于完全恢复模式，并进行频繁的日志备份。每个日志备份将包含自上次日志备份以来的所有事务。日志备份过程还负责清除日志并标记可重复使用的空间，即，将以循环方式将DB中进行的下一个事务写入到截断日志的开头。日志的这种备份和重用可以防止日志文件增长。

如果您对时间点恢复不感兴趣，并希望简化数据库的管理。然后将数据库设置为简单恢复模型，并且不进行t-log备份。提交每个事务后，SQL Server将自动截断事务日志。意味着一旦将事务提交到日志，记录将被下一个事务等覆盖。

无论哪种方式，一旦您做出了这两个决定之一，就可以将日志文件缩小到更合理的大小。请注意，理想情况下，您希望使其足够大，这样它就不会增大，但又不会太大，以至于需要再次缩小它。还要注意，您不能缩小日志的活动部分。

下载并部署https://ola.hallengren.com/数据库管理解决方案，以涵盖备份，索引碎片，统计信息和CHECKDB。

您还可能会发现通过右键单击对象资源管理器>报告>标准报告>“磁盘使用情况”中的数据库返回的“磁盘使用情况”报告，对于返回t日志中的可用空间很有用。

我还建议您从Google的角度出发，为什么保持日志链完整如此重要如此重要，以及如何从完整切换到简单会破坏链条，从而使您面临数据丢失的问题。

看到我们在午夜进行常规的完整数据库备份时，对我来说暂时将数据库置于“简单恢复模式”（在其中一种备份运行之后），收缩日志文件以收回（几乎所有）空间以及然后使用上述备份策略将其放回完全恢复中？

是的，这样做很安全，只要您在进行此操作时不干扰任何事务（例如深夜装货）。通常，如果数据库应处于完全恢复模式，则需要常规的T-Log备份。这将减少您面临的问题。我之所以写“大体”，是因为在某些情况下，我已经看到人们将数据库设置为已满，却不知道他们为什么这么做。我们假设情况并非如此。

但是，您可能要考虑为什么日志的大小相对于数据库大小而言如此。一个500MB的数据库和一个116GB的日志对于一次事件似乎显得不合比例。我建议监视数据库中发生的事情，首先查看它如何达到该大小。