Version control tfs数据库大小-版本控制

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

查看SQL Server中的表，似乎罪魁祸首是tbl_内容表，它的容量为70 GB。如果我对所有项目的整个源代码树进行一次获取，它只有大约8GB的数据

这只是所有文件的历史记录吗？这似乎是一个10:1的比例，只是历史…因为我认为三角洲会非常小

有人知道，如果源容量为8GB（活动时间为2年），这是否是一个合理的大小吗？如果不是的话，应该看什么来“修复”这个问题

---

谢谢

我现在帮不上忙比率问题，对不起。对于短期修复，您可以检查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

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

---

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

这是关于您所指的二进制文件的链接，是的！我很高兴你找到了它，因为我最近“重新整理”我的书签时似乎把它弄丢了。：-）