略微更新的答案，针对MSSQL 2017，并使用SQL服务器管理工作室。 我基本上是从这些指示https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

我有一个最近的数据库备份，所以我备份了事务日志。然后我又备份了一次。 最后，我缩小了日志文件，从20G减小到7MB，这更符合我的数据大小。 自从2年前安装这个系统以来，我认为交易日志从来没有备份过。所以把这项任务写在家务管理日历上。

这是一种简单且不优雅且有潜在危险的方法。

备份数据库 分离数据库 重命名日志文件 附加数据库 将重新创建新的日志文件 删除重命名日志文件。

我猜您没有做日志备份。(截断日志)。我的建议是将恢复模式从完全恢复改为简单恢复。这将防止日志膨胀。

其他一些答案对我来说不适用:当db在线时不可能创建检查点，因为事务日志已满(多么讽刺)。但是，在将数据库设置为紧急模式后，我能够收缩日志文件:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

免责声明:在尝试之前请仔细阅读下面的评论，并确保检查接受的答案。就像我5年前说的:

如果有人有任何评论要补充的情况下，这不是一个 适当的或最优的解决方案，然后请在下面评论

事实证明有:-)

最初的回答:

右键单击数据库名称。 选择“任务→收缩→数据库” 然后单击“确定”!

我通常打开包含数据库文件的Windows资源管理器目录，所以我可以立即看到效果。

我真的很惊讶这竟然能起作用!通常我以前使用DBCC，但我刚刚尝试了一下，它没有缩小任何东西，所以我尝试了GUI(2005)，它工作得很好——在10秒内释放了17 GB

在完全恢复模式下，这可能不起作用，因此您必须首先备份日志，或者更改为简单恢复，然后收缩文件。[感谢@onupdatecascade]

--

PS:我很欣赏一些关于这种危险的评论，但在我的环境中，我自己这样做没有任何问题，尤其是因为我总是先做完全备份。因此，在继续之前，请考虑您的环境，以及这会如何影响您的备份策略和工作安全性。我所做的一切只是把人们指向微软提供的一个功能!

数据库→右键单击属性→文件→添加另一个不同名称的日志文件，并将路径设置为与旧日志文件相同，只是文件名不同。

数据库自动获取新创建的日志文件。

如果不使用事务日志进行恢复(即只进行完全备份)，可以将恢复模式设置为“简单”，那么事务日志很快就会缩小，再也不会被填满。

如果您使用SQL 7或2000，您可以在数据库选项选项卡中启用“截断检查点日志”。这有同样的效果。

显然，在生产环境中不建议这样做，因为您将无法恢复到某个时间点。