如何缩小SQL Server日志文件的大小

我不知道如何缩小数据库ldf文件的大小。

DBA说我应该使用 backup log dbname with truncate_only

尽管看起来它可以在SQL查询分析器中正确执行，但ldf文件仍然超过2 Gb。

**基于以下一些评论和一些答案进行澄清。***有问题的特定数据库是我的笔记本电脑上的数据库，我仅将其用于开发过程。日志文件正在增长到看起来导致磁盘已满的地步。没有生产风险。我了解我提出的问题和接受的答案在生产环境中存在风险。*

sql-server log-files shrink

— 罗恩·塔芬
source

当然这是一个重复的问题？

— JamesRyan

我查看了一下，发现只有一个正在询问有关SHRINKFILE何时失败的问题。当时没有任何意义，所以我发布了这个问题。我确实考虑过删除问题，但后来我发现在同一船上还会有其他人。如果您发现一个重复的问题（实际上是在问相同的问题，而不是相似的问题），那么我很乐意删除该问题。

— 罗恩·塔芬

搜索的第一页上大约包含8个答案，但我想您必须知道要搜索的内容。我经常看到它作为答案的一部分，我感到惊讶的是，它并没有以如此直接的方式被问到。

— JamesRyan 2010年

答案很大程度上取决于数据库的恢复选项：简单还是完整？

— 理查德2010年

感谢您的澄清，罗恩。由于它是一个dev数据库，因此除了缩小日志文件之外，您还需要将恢复模型更改为SIMPLE，否则问题将再次发生。

— BradC

Answers:

哦，恐怖！请不要告诉别人他们应该缩小日志文件！

如果您遇到这种情况，则极有可能出现以下情况之一：

您的数据库处于完全恢复模式，它实际上应该处于简单模式
您的数据库处于完全恢复模式，应该定期备份日志
您的数据库处于完全恢复模式，并且由于某些原因您的日志备份失败
您正在运行巨大的事务，这些事务正在将日志文件放大为大量

这些问题的答案如下：

如果为（1），则将数据库切换为简单模式；
如果为（2），则计划定期日志备份；
如果为（3），则修复计划的日志备份；
如果为（4），则不要这样做：)小批量工作。

请注意，这些都不要求使用（不建议使用的）“带有truncate_only的备份日志数据库名称”

相反，一旦您使用上述一种方法清除了日志文件，然后使用以下方法缩小（现在为空）日志：

DBCC SHRINKFILE ('log logical name', 2000)

始终指定一个合理的最终大小，否则它将缩小到接近0，并且下次需要它时，必须花一些时间来增长。

— 布拉德
source

太糟糕了，被接受的答案是如此之快。这是我在面试中淘汰SQL管理员的问题之一。如果他们返回了带有truncate_only的备份，则算是2分。

— Jim B 2010年

我同意，绝对要做的最后一件事情就是缩小文件。正确的维护消除了对此的需要。但是一旦它变大并且想要变小，就必须缩小它。但是，缩小时，最好将文件缩小得尽可能小，然后以8GB的增量将文件增长到正确的大小。这将优化文件中的VLF数量。请参见-sqlskills.com/BLOGS/KIMBERLY/post/…。

— 布赖恩·奈特

有趣的链接，似乎它仅在您的跨日志超过8Gb时适用。我认为BradC的观点（或至少是我的观点）是，确实有紧急情况会诱使您缩小日志文件，但您应该认识到，如果运行臭名昭著的备份/ w trunc，然后运行rinklefile，您就已经使备份链失效了（希望这没什么重要的），除了磁盘空间问题外，您还很可能从数据库设计角度或从架构角度考虑了一些严重的sql server问题。如果不解决潜在的问题，您最多只能花一些时间。

— Jim B 2010年

在执行“使用truncate_only备份”之后，您应该发出以下命令来缩小

dbcc SHRINKFILE (logfilename,shrink_tosize)

例如

dbcc SHRINKFILE (mydatabase_Log,512)

— 马尼
source

您上面编写的脚本将标记日志内容以供重用。使用以下脚本：

USE <database>;

DBCC SHRINKFILE (<log logical file name>)

那将为您缩小它。

— 布莱恩·奈特
source