下面是收缩事务日志的脚本，但是我强烈建议在收缩之前备份事务日志。

如果你只是缩小文件，你将失去大量的数据，这些数据在灾难发生时可能会成为救星。事务日志包含大量有用的数据，可以使用第三方事务日志读取器读取(可以手动读取，但需要付出很大的努力)。

当涉及到时间点恢复时，事务日志也是必须的，所以不要把它扔掉，而是要确保事先备份它。

以下是人们使用存储在事务日志中的数据来完成恢复的几篇文章:

如何查看SQL Server 2008的事务日志 读取SQL Server 2008中的日志文件(*.LDF)

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

当执行上面的命令时，您可能会得到类似这样的错误

"不能收缩日志文件(日志文件名)，因为逻辑 位于文件末尾的日志文件正在使用"

这意味着正在使用TLOG。在这种情况下，尝试在一行中多次执行该命令，或者找到减少数据库活动的方法。

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

来自事务日志神话:

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

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

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

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

下面是收缩事务日志的脚本，但是我强烈建议在收缩之前备份事务日志。

如果你只是缩小文件，你将失去大量的数据，这些数据在灾难发生时可能会成为救星。事务日志包含大量有用的数据，可以使用第三方事务日志读取器读取(可以手动读取，但需要付出很大的努力)。

当涉及到时间点恢复时，事务日志也是必须的，所以不要把它扔掉，而是要确保事先备份它。

以下是人们使用存储在事务日志中的数据来完成恢复的几篇文章:

如何查看SQL Server 2008的事务日志 读取SQL Server 2008中的日志文件(*.LDF)

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

当执行上面的命令时，您可能会得到类似这样的错误

"不能收缩日志文件(日志文件名)，因为逻辑 位于文件末尾的日志文件正在使用"

这意味着正在使用TLOG。在这种情况下，尝试在一行中多次执行该命令，或者找到减少数据库活动的方法。

-- 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)

您可能需要先备份。

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

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