首先检查数据库恢复模型。默认情况下，SQL Server Express Edition会为简单恢复创建一个数据库 (如果我没记错的话)。

备份日志DatabaseName With Truncate_Only

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile将为您提供逻辑日志文件名。

请参考:

从SQL Server数据库中的完整事务日志中恢复

如果您的数据库处于完全恢复模式，并且您没有进行TL备份，那么将其更改为SIMPLE。

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

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

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

它发生在我身上，数据库日志文件是28 gb。

你能做些什么来减少这种情况呢? 实际上，日志文件是SQL服务器在事务发生时保存的文件数据。对于要处理的事务，SQL服务器为其分配页面。但在交易完成后，它们不会突然被释放，希望可能会有类似的交易到来。这撑起了空间。

步骤1: 首先在已探索的数据库查询中运行此命令 检查点

步骤2: 右键单击数据库 任务>备份 选择备份类型为事务日志 添加目标地址和文件名以保存备份数据(.bak)

再次重复此步骤，此时给出另一个文件名

步骤3: 现在转到数据库 右键单击数据库

>收缩>文件 “文件类型”选择“日志” 收缩动作释放未使用空间

步骤4:

检查日志文件 通常在SQL 2014中可以在

C:\Program Files\Microsoft SQL Server\MSSQL12。MSSQL2014EXPRESS \该\数据

在我的例子中，它从28 GB减少到1 MB

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

来自事务日志神话:

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

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