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

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

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

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

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

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

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

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

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

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

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

备份数据库 分离数据库 重命名日志文件 附加DB(同时附加删除重命名的.ldf(日志文件)。选择它并按下删除按钮) 将重新创建新的日志文件 删除重命名日志文件。

这可以工作，但建议先备份数据库。

截断日志文件。

备份数据库 卸载数据库，可以使用Enterprise Manager，也可以执行以下命令: 删除事务日志文件。(或重命名文件，以防万一) 使用Sp_AttachDB [DBName]重新连接数据库 当附加数据库时，将创建一个新的事务日志文件。

使用实例收缩日志文件。

使用No_Log备份日志[DBName] 通过以下方式收缩数据库: 使用企业管理器:- 右键单击数据库，所有任务，收缩数据库，文件，选择日志文件，确定。 使用T-SQL:- Dbcc Shrinkfile ([Log_Logical_Name])

您可以通过运行sp_helpdb或在Enterprise Manager中查看数据库的属性来查找日志文件的逻辑名称。

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

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

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

到目前为止，这里的大多数回答都假设您实际上并不需要事务日志文件，但是，如果您的数据库使用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)