我被要求分析一个与 biztalk 服务器有关的问题。我被要求释放某个驱动器上的空间，我发现唯一的文件 BiztalkMsgBoxDB_log.bak 占用了驱动器的近 90%。运行以下查询后，我发现使用的日志空间仅为 1.25%。
EXEC ('DBCC sqlperf(LOGSPACE) WITH NO_INFOMSGS')
**Database Name** **Log Size (MB)** **Log Space Used (%)** **Status**
BizTalkMsgBoxDb 24930.49 1.257622 0
当前恢复模式为：完整，并且事务日志备份是在一小时前进行的。
我不知道为什么日志文件创建得这么大。我该如何释放此驱动器上的数据。
答案1
你应该缩小你的日志。不要删除它！
在 SQL Server MGMNT Studio 中，右键单击您的数据库，任务 > 收缩 > 文件。选择您的日志（如下图所示）（或收缩到适合您的大小），然后单击确定。
您可能需要随后查看自动增长设置并设置限制，以确保将来不会发生这种情况。
我最推荐的做法是将日志文件放在单独的磁盘上（如果无法添加额外的磁盘，则放在分区上）。这样，日志文件就可以填满驱动器而不会中断任何其他操作。（顺便说一下，tempdb 也是如此）。
如果运行此命令后日志文件仍然这么大，则可能仍有事务阻止该操作。尝试使用sp_who2或查找它sp_whoisactive看看你是否能阻止它。如果你不只是杀死它，还可以获得额外积分。
确保它没有卡在某个复制上。您可以尝试将数据库置于简单模式并恢复为完整模式，但这应该是最后的手段。之后别忘了检查您的备份！
答案2
假设 SQL Server 正在运行，您将无法真正删除该文件，并且该文件实际上是 SQL Server 正在使用的数据库的日志文件。您已识别出名称以结尾，.bak这通常是为 SQL Server 保留的备份文件，而不是日志文件。通常，日志文件扩展名为.ldf。如果它确实是备份文件，您可以删除它；但是，如果 SQL Server 定期备份该文件，它当然会在下次备份时重新出现。您可能不想删除备份文件，因为它对于灾难恢复可能至关重要。
SQL Server 日志文件包含对数据库本身所做的每项修改的记录。备份日志通常会标记文件的部分内容以供重复使用，因此如果您在DBCC LOGPERF备份后查看，您可能会想知道为什么日志文件“这么大”，而它只使用了 1%。在缩小文件之前，您可能希望确定文件所需的大小，因为 SQL Server可能下次对数据库进行维护时，只需将文件恢复到该大小即可。日志文件增大的原因有很多，当它增大时，会暂时大大降低响应时间。参见这个问题以及有关更多详细信息的答案dba.stackexchange.com地点。