相关疑难解决方法(0)

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

在 SQL Server 中 -

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

我在生产数据库中有一个表，其大小为 525 GB，其中 383 GB 未使用：

我想回收其中的一些空间，但是，在弄乱生产数据库之前，我正在测试数据库中数据较少的相同表上测试一些策略。这个表有一个类似的问题：

关于表的一些信息：

• 填充因子设置为 0
• 大约有 30 列
• 其中一列是图像类型的 LOB，它存储的文件大小从几 KB 到几百 MB
• 该表没有任何与之关联的假设索引

服务器正在运行 SQL Server 2017 (RTM-GDR) (KB4505224) - 14.0.2027.2 (X64)。数据库正在使用SIMPLE恢复模型。

我尝试过的一些事情：

• 重建索引：ALTER INDEX ALL ON dbo.MyTable REBUILD. 这产生了微不足道的影响。
• 重新组织索引：ALTER INDEX ALL ON dbo.MyTable REORGANIZE WITH(LOB_COMPACTION = ON). 这产生了微不足道的影响。

• 将 LOB 列复制到另一个表，删除该列，重新创建该列，并将数据复制回来（如这篇文章所述：释放未使用的空间 SQL Server 表）。这减少了未使用的空间，但似乎只是将其转换为已用空间：

  

• 使用 bcp 实用程序导出表、截断它并重新加载它（如这篇文章所述：如何为表释放未使用的空间）。这也减少了未使用的空间并增加了与上图类似的程度。

• 即使不推荐，我也尝试了 DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 命令，但它们对未使用的空间没有任何影响。
• 跑步DBCC CLEANTABLE('myDB', 'dbo.myTable')没什么区别
• 在保持图像和文本数据类型以及将数据类型更改为 varbinary(max) 和 …