截断 SQL Server 日志文件的命令是啥？

Posted 2023-02-26

【中文标题】截断 SQL Server 日志文件的命令是啥？

【英文标题】：What is the command to truncate a SQL Server log file?截断 SQL Server 日志文件的命令是什么？

【发布时间】：2010-09-07 14:40:58

【问题描述】：

在发送给同事之前，我需要清空 LDF 文件。如何强制 SQL Server 截断日志？

【参考方案1】：

在管理工作室：

不要在实时环境中执行此操作，但要确保尽可能缩小开发数据库： 右键单击数据库，选择Properties，然后选择Options。 确保“恢复模式”设置为“简单”，而不是“完整” 点击确定 再次右键数据库，选择Tasks -> Shrink -> Files 将文件类型更改为“日志” 点击确定。

或者，执行此操作的 SQL：

 ALTER DATABASE mydatabase SET RECOVERY SIMPLE
 DBCC SHRINKFILE (mydatabase_Log, 1)

参考：http://msdn.microsoft.com/en-us/library/ms189493.aspx

【讨论】：

您的回答拯救了我的一天！我不知道“右键单击-任务->收缩”选项。谢谢！

您在现场环境中做什么？先备份日志？

我不是 DBA，但是是的，我相信备份日志会截断它：technet.microsoft.com/en-us/library/ms179478.aspx

@JohnBubriski 如果您使用的恢复模式不是简单的，那么日志是恢复数据或回滚事务的基础。因此，在生产环境中，您需要先备份这些日志，然后才能压缩日志文件。否则，就没有实际恢复的可能性。不幸的是，如果您处于恢复状态，则必须重新加载所有事务日志备份才能完全恢复数据库。欢乐时光，当然！ :)

在 SQL Server 2012 中我必须 use mydatabase 才能执行 dbcc shrinkfile

【参考方案2】：

如果我没记错的话……在查询分析器或同等工具中：

BACKUP LOG  databasename  WITH TRUNCATE_ONLY

DBCC SHRINKFILE (  databasename_Log, 1)

【讨论】：

这绝对比将数据库恢复模型设置为 SIMPLE 更好（如 Blorgbeard 的回答），因为如果您的恢复模型是 FULL，那么您设置它是有原因的。

truncate_only 在 SQL Server 2008 中已弃用，因此您必须将数据库切换到简单恢复 msdn.microsoft.com/en-us/library/ms143729(SQL.90).aspx

对于 SQL Server 2012 这可以工作，但没有 WITH TRUNCATE_ONLY。

补充 net_prog 所说的，对于 SQL Server 2012，我将第一行替换为 BACKUP LOG DatabaseNameHere TO DISK='NUL:'。

'TRUNCATE_ONLY' 不是公认的备份选项。 (SQL Server 2019 RC1)

【参考方案3】：

对于 SQL Server 2008，命令是：

ALTER DATABASE ExampleDB SET RECOVERY SIMPLE
DBCC SHRINKFILE('ExampleDB_log', 0, TRUNCATEONLY)
ALTER DATABASE ExampleDB SET RECOVERY FULL

这将我的 14GB 日志文件减少到 1MB。

【讨论】：

由于关于哪个版本的问题不明确，并且接受的答案不适用于 SQL Server 2008，因此无论年龄大小，此答案仍然有效。

谢谢，它帮助我减少了一个与 DBCC SHRINKFILE 没有反应的大日志文件

完成后别忘了将恢复模式改回 FULL！

您应该在执行此操作之前备份（或任何其他截断选项）。如果您进行完整备份并检查 SSMS 中的“仅复制备份”，则您不再需要该日志。 （这只是一个时间点备份）。

【参考方案4】：

对于 SQL 2008，您可以将日志备份到 nul 设备：

BACKUP LOG [databaseName]
TO DISK = 'nul:' WITH STATS = 10

然后使用DBCC SHRINKFILE 截断日志文件。

【讨论】：

这是唯一一个最终在我的情况下工作的...我尝试使用 TRUNCATE_ONLY 备份时出错

注意：这可能需要很长时间，即使在 SSD 上也是如此（它必须读取日志才能丢弃它）。对于功率适中的 Azure VM 上的 30GB 日志文件，需要 10 分钟才能完成 40%。确保切换到 SSMS 中的“消息”以查看处理的百分比。

【参考方案5】：

使用 truncate_only 后跟 dbcc shrinkfile 命令的备份日志 logname

【参考方案6】：

因为我的答案被埋在了 cmets 中。对于 SQL Server 2012 及更高版本，您可以使用以下内容：

BACKUP LOG Database TO DISK='NUL:'
DBCC SHRINKFILE (Database_Log, 1)

【参考方案7】：

另一种选择是通过 Management Studio 分离数据库。然后只需删除日志文件，或重命名并稍后删除。

返回 Management Studio 再次附加数据库。在附加窗口中，从文件列表中删除日志文件。

数据库附加并创建一个新的空日志文件。确认无误后，即可删除重命名的日志文件。

您可能不应该将它用于生产数据库。

【讨论】：

永远不要这样做！日志中可能有尚未提交到数据文件的数据。您会丢失此类数据。

如果在您的回答中，您警告不要在生产中尝试它，那么根本不值得发布。

我不同意反对者的观点——这是一种选择。管理员只需要了解他们的场景。例如——如果没有打开的交易，就不会有“未提交”的数据。

这是唯一对我有用的解决方案。我的驱动器已满，我无法备份或缩小，而且似乎没有其他任何工作。谢谢！

我同意；这不是最佳实践，但如果您没有其他选择（例如 Brian 的场景），它是一种有价值的工具。