相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

可能的重复：
为什么事务日志不断增长或空间不足？

我的 SQL Server 中有一个 300 GB 的数据库日志。我想缩小所有日志，但它不允许我这样做。我尝试在 SQL Server 2008 R2 中使用查询和 UI。我用了

USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO

但是没有任何错误，数据库日志不会缩小。

然后我想使用另一种方法，如下所示：

我将从 SQL Server 分离数据库，然后在将特定.LDF文件移动到其他位置后，仅将数据库文件附加回 SQL Server。我能够成功地将所有日志从 SQL Server 移动到其他服务器。

请让我知道这是将事务日志移动到其他驱动器的好习惯。如果没有，请建议一些其他解决方案来从收缩的数据库日志中恢复。

我似乎想不出答案。我见过多个这样的答案： 为什么事务日志不断增长或空间不足？

每个人都在谈论在您的日志文件上运行备份，以便它缩小。我正在这样做，但它不会缩小任何东西！我也不相信我正在运行任何超长事务。

服务器： SQL Server 2008

恢复模式： Full

我有一个维护计划来存储 5 天的备份。任务 1 备份具有备份类型的数据库Full，任务 2 备份事务日志。Verify backup integrity对两个任务都进行检查。

我的数据库的正常.ldf文件是 22GB。当我运行上述任务时，.bak文件为435mb，但.trn.文件为22gb，与ldf相同。并且在成功运行之后.ldf根本没有缩小，尽管我读过的所有内容都告诉我应该这样做？

这里发生了什么，为什么日志文件永远不会缩小？

我也试过运行另一个答案中提到的这个命令：

select name, log_reuse_wait_desc from sys.databases

它说LOG_BACKUP的是带有巨大日志文件的数据库。

根据下面的答案，我混淆了已用空间的分配。这些是我的统计数据：

由于我不知道为什么，初始大小设置为 22gb ...

每季度，我通过 CMS 使用来自github 上的tigertoolbox/Fixing-VLFs/的查询检查我所有服务器上的 VLF 。这包括用于更正所发现内容的建议（和代码）。在进行任何调整之前，我总是尝试充分了解正在发生的事情。我应用的 VLF 解决方案在 90% 的情况下与建议不同，尽管它通常很接近。

使用DBCC LOGINFO我发现有几个 VLF 没有按顺序使用。我试图理解为什么。这个高度投票的答案; 即使在 BACKUP LOG TO DISK说它可能发生后，日志文件上的 DBCC SHRINKFILE 也不会减小大小 ，但不是为什么。

因为虚拟日志文件并不总是按顺序分配的，

这似乎与Jonathan Kehayias相冲突；一天的 XEvent（31 个中的 23 个）——它是如何工作的——多个事务日志文件

我们可以看到，在 130 VLF 中，目前仅使用了两个（第 51 和 52 行）。最大的 FSeqNo 是 41808，减去 130 = 41678。我没有看到任何低于 41678 的 FSeqNo，所以大概在最近的 130 次 VLF 翻转中都使用了。

如果我们查看第 108 - 109 行，我们会看到第 110 行首先被写入，然后是第 109 行，然后是第 108 行。而且奇偶校验关闭（不确定这会增加场景的内容）LSN 显示它们是在相反的位置创建的命令。

我希望一旦导致顺序中断的原因过去了，下一次通过 VLF 将按创建的顺序写入。为什么不是？

注意第 86 …