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

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

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

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

DB事务日志收缩到最小大小:

备份:事务日志 收缩文件:事务日志 备份:事务日志 收缩文件:事务日志

我在几个db上做了测试:这个序列工作。

它通常缩小到2MB。

或通过脚本:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

SQL Server事务日志需要适当地维护，以防止其不必要的增长。这意味着要经常运行事务日志备份。如果不这样做，您就有可能使事务日志变得满并开始增长。

除了这个问题的答案，我建议阅读和理解事务日志的常见错误。这些阅读可能有助于理解事务日志，并决定使用什么技术来“清除”它:

从10个最重要的SQL Server事务日志神话:

Myth: My SQL Server is too busy. I don’t want to make SQL Server transaction log backups One of the biggest performance intensive operations in SQL Server is an auto-grow event of the online transaction log file. By not making transaction log backups often enough, the online transaction log will become full and will have to grow. The default growth size is 10%. The busier the database is, the quicker the online transaction log will grow if transaction log backups are not created Creating a SQL Server transaction log backup doesn’t block the online transaction log, but an auto-growth event does. It can block all activity in the online transaction log

来自事务日志神话:

神话:定期收缩日志是一种很好的维护实践 假的。对数增长非常昂贵，因为新块必须归零。该数据库上的所有写活动都停止，直到归零完成，如果磁盘写很慢或自动增长的大小很大，那么暂停可能很长，用户会注意到。这就是为什么你要避免增长的原因之一。如果您缩小日志，它将再次增长，您只是浪费磁盘操作在不必要的收缩和增长游戏

到目前为止，这里的大多数回答都假设您实际上并不需要事务日志文件，但是，如果您的数据库使用FULL恢复模型，并且您希望保留备份以备需要恢复数据库时使用，那么不要像许多回答所建议的那样截断或删除日志文件。

删除日志文件(通过截断它、丢弃它、擦除它等)将破坏备份链，并将阻止您恢复到上一次完整、差异或事务日志备份以来的任何时间点，直到进行下一次完整或差异备份。

来自微软关于备份的文章

我们建议不要手动使用NO_LOG或TRUNCATE_ONLY 截断事务日志，因为这会中断日志链。直到 下一次全量或差异数据库备份时，数据库不备份 防止媒体故障。仅在very中使用手动日志截断 特殊情况，并立即创建数据备份。

要避免这种情况，请在收缩日志文件之前将其备份到磁盘。语法应该是这样的:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)