使用DBCC ShrinkFile ({logicalLogName}， TRUNCATEONLY)命令。如果这是一个测试数据库，并且您试图节省/回收空间，这将有所帮助。

记住，TX日志确实有一个最小/稳定状态大小，它们将逐渐增长。根据您的恢复模型，您可能无法收缩日志-如果是FULL且您没有发布TX日志备份，则日志不能收缩-它将永远增长。如果不需要TX日志备份，请将恢复模式切换为Simple。

记住，在任何情况下都不要删除日志(LDF)文件!您几乎会立即破坏数据库。煮熟的!完成了!数据丢失!如果“未修复”，主MDF文件可能会永久损坏。

永远不要删除事务日志-你会丢失数据!你的部分数据在TX日志中(不管哪种恢复模式)…如果分离并“重命名”TX日志文件，将有效地删除数据库的一部分。

对于那些已经删除了TX日志的用户，您可能希望在丢失更多数据之前运行一些checkdb命令并修复损坏。

看看保罗·兰德尔关于这个话题的博客文章，糟糕的建议。

此外，一般不要在MDF文件上使用收缩文件，因为它会严重破坏你的数据。查看他的坏建议部分以获得更多信息(“为什么你不应该缩小你的数据文件”)

看看保罗的网站，他讨论了这些问题。上个月，他在他的“一天的神话”系列文章中探讨了许多这样的问题。

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

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

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

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

从DBCC SHRINKFILE (Transact-SQL)

您可能需要先备份。

不推荐John推荐的这种技术，因为没有日志文件就不能保证数据库会附加。将数据库从full更改为simple，强制设置检查点并等待几分钟。SQL Server将清除日志，然后使用DBCC SHRINKFILE收缩日志。

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

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

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