这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：
在 SQL Server 中 -
- 事务日志变得如此之大的一些原因是什么？
- 为什么我的日志文件这么大？
- 有什么方法可以防止这个问题的发生？
- 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？
sql-server shrink transaction-log auto-growth recovery-model
我有一个 302MB 的日志文件。
我做了一个日志备份，它使日志文件大部分都是免费的（我可以通过磁盘使用标准报告看到这一点）
如果我试着跑
DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0, TRUNCATEONLY)
或者
DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0)
该文件仍显示为 302MB。
我知道我可以将数据库更改为简单恢复，然后运行上述命令之一并设置回完全恢复（然后进行完全备份以确保数据库未处于伪简单恢复模式）
但是，为什么我不能在完全恢复模式下缩小文件？
我知道收缩不是你应该做的事情，但在我现实世界的数据库中，因为没有人备份过它已经增长到 30GB 的事务日志，现在已经实施了定期日志备份以防止这个级别的增长
我有几个带有事务日志的 SQL Server 2008 数据库，这些数据库已经失控并填满了驱动器。这些日志之一是 68gb yikes。
我知道最好不要通过截断日志来终止我的备份链，但是当我单独进行收缩时，在几个数据库上我没有任何空间回收，而在我做的那些上，数量可以忽略不计。我已经验证客户端每小时运行一次 t-log 备份，并且这些备份在过去几周内都成功了。
显然我错过了一些东西。有人可以指出我正确的方向，还是我只是不得不手动截断并祈祷在此期间什么也没有发生？