Question

我在单个服务器上安装了TFS，磁盘空间不足。（我们现在已经使用该实例大约2年了。）

查看SQL Server中的表格似乎是罪魁祸首是tbl_content表，它是70 GB。如果我为所有项目获取整个源代码树，那么它只有大约8 GB的数据。

这只是文件的所有历史记录吗？这似乎只是历史上10：1的比例...因为我认为增量会非常小。

有没有人知道如果给出8 GB的来源（以及2年的活动），这是否合理？如果没有什么可以看到'修复'这个？

由于

Answer 1

此刻我对比率问题无能为力，抱歉。对于短期修复，您可以检查DB文件中是否有可以释放的空间。你可能已经，但如果没有..

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

如果上面的语句返回了您想要恢复的空间，您可以查看一次性DBCC SHRINKDATABASE或DBCC SHRINKFILE以及可能包括对数据库进行碎片整理的调度例程SQL维护计划。

DBCC SHRINKDATABASE和DBCC SHRINKFILE不是您应该定期执行的操作，因为SQL Server需要一些“交换”空间来移动以获得最佳性能。因此，不应该依赖它们作为您的长期修复，并且两者都可能导致TFS响应时间的某些显着性能下降。

JB

Answer 2

您是否每天都看到数据增长，即使系统上没有活动？如果答案是肯定的，你是否在某个地方存储了8GB以外的任何二进制文件？

我问的原因是，如果TFS无法计算增量或文件超过增量生成的大小，TFS将复制整个二进制文件。我没有与我的链接，但我在我的工作机器上有它，它描述了这个场景以及如何解决它，如果这是你的问题的原因。