减少 SQL 日志文件大小的正确过程答案

【问题标题】：Correct process for reducing SQL Log file size减少 SQL 日志文件大小的正确过程
【发布时间】：2019-09-19 13:48:02
【问题描述】：

SQL 2008 R2。每晚进行完整备份，并复制到第二台服务器以进行报告。业务关键的多个数据库。 SQL 日志文件有超出可用磁盘空间的危险

Shrinkfile 似乎没有效果。创建日志文件的备份，然后选择 GUI 选项来缩小日志文件。完成此日志文件大小后，更易于管理。什么时候可以安全地删除日志文件备份，或者永远不会？

【问题讨论】：

你指的是事务日志吗？
@a_horse_with_no_name 他似乎在混合问题、备份和事务日志文件。
很遗憾我原来不够清楚。每晚备份数据库，然后全天更频繁地备份日志文件。成功（我认为）减小了日志文件的大小（它似乎没有再次增长），我什么时候可以删除已采取的日志文件备份？一旦进行了新的完整数据库备份，它是否是多余的，并且新的较小的日志文件备份是否足够，而无需保留我必须采取的日志文件的完整备份才能使其缩小。希望我让我的问题（和缺乏理解）更清楚？

【解决方案1】：

您需要为可能用于恢复数据库的完整备份保留事务日志备份。例如。如果您保留最后 7 次完整备份，则只需保留上周的日志备份，以便在出现问题时将数据库恢复到一周中的任何时间点。

【讨论】：

回答了要保留哪些备份，但您可能需要补充一点，事务日志大小只能在完整备份后减小/缩小。
如果定期积压trx日志，则不需要收缩日志文件。备份后空间将被重新使用，文件大小意味着 SQL 服务器在备份期间需要该空间量用于事务。如果缩小，文件将再次增长到大小
感谢您在这里的回答。我仍然有点困惑，并希望您今天看到我对原始查询的附加评论。在上面的评论中，您是指您写“积压”的“备份”吗？我不相信事务日志通常由自动化流程备份，只写入备份。抱歉，我想我在这里搞糊涂了。
事务日志备份文件曾经比对应的数据库备份文件大很多。由于我原始帖子中的过程，事务日志备份文件现在比相应的数据库备份文件和可用空间受到的威胁更小。您在上面说过它会恢复到原来的大小，但这不是我所看到的 - 还是我误解了？
这取决于您之前备份事务日志的方式以及一些数据库维护活动（如 DBCC checkdb）的计划。例如，如果您每周安排一次 DBCC checkdb，您可能会看到 trx 日志在那之后增长了很多。