我们目前正在TFS数据库中遇到大量等待，并且正在尝试了解这些是否是数据库中tbl_Version版本历史记录表大小的结果。
目前，该表包含超过2000万条记录，占用大约6GB的存储空间（总索引空间刚刚超过10GB）。查看SQL Server必须处理的查询，只要访问此表，我们就会有高PAGEIOLATCH_SH等待。显然，我们无法控制在数据库中抛出的查询（TFS的所有部分）。
目前我们在虚拟机上有TFS，本质上想要了解我们是否应该（a）移动到物理机器，（b）尝试减少tbl_version的大小或（c）遵循这些的组合
在我们的组织中，转移到物理服务器并不是一件容易的事情，因此我想在做出任何此类决定之前，先了解我们的表格大小是否“正常”。
答案 0 :(得分：6)
PageLatch_SH通常表示等待页面从磁盘加载到内存。从它的声音来看，tbl_Version并没有留在内存中。你可以做两件事来改善这种情况：
一个。获得更多RAM（不确定服务器上有多少RAM）。 湾获得更快的磁盘子系统。
在TFS 2010中，如果您拥有Enterprise Edition of SQL，我们会启用页面压缩。这应该有助于解决问题。
答案 1 :(得分：0)
根据微软2007年的一些统计数据：http://blogs.msdn.com/b/bharry/archive/2007/03/13/march-devdiv-dogfood-statistics.aspx可能不是最大的。
但是MS（正如该博客中所述）进行了一些数据库调优，我认为这是在TFS 2010中，但对于早期版本，您可能需要与MS直接对话。
答案 2 :(得分：0)
警告：我们正在使用TFS 2008。
我们目前正在使用大约9GB的数据（18GB索引）和31M行。这是在拥有50-60名活跃开发人员的IS商店使用约一年半之后。
我们仍然需要解决的部分问题是存储在版本控制系统中的大型二进制文件。我的问题here的答案可能会提供一些信息，说明是否有少数主要罪犯导致该表的大小超出您想要的范围。