☰

TFS 2015 CodeSense 清理

tag-icon • tag-icon team-foundation-server
TFS 2015 CodeSense 清理

我最近接手了管理 TFS 实例的责任，但我之前没有经验。在过去的 6 个月里，团队项目的数据库似乎异常庞大，阅读我能找到的所有内容帮助我（我认为）找到了罪魁祸首，但我不知道该怎么做。任何帮助都将不胜感激。

我运行了一些广泛使用的查询，例如这个：

SELECT TOP 3 o.name, 
SUM(reserved_page_count) * 8.0 / 1024 SizeInMB,
SUM(CASE 
WHEN p.index_id <= 1 THEN p.row_count
ELSE 0
END) Row_Count
FROM sys.dm_db_partition_stats p
JOIN sys.objects o
ON p.object_id = o.object_id
GROUP BY o.name
ORDER BY SUM(reserved_page_count) DESC

要找到它：

name             SizeInMB       Row_Count
tbl_Content      313489.765625  10090278
tbl_Version      33400.828125   27518951
tbl_AggregateMap 10638.539062   32955145

还有另一个查询：

SELECT Owner = 
CASE
WHEN OwnerId = 0 THEN 'Generic' 
WHEN OwnerId = 1 THEN 'VersionControl'
WHEN OwnerId = 2 THEN 'WorkItemTracking'
WHEN OwnerId = 3 THEN 'TeamBuild'
WHEN OwnerId = 4 THEN 'TeamTest'
WHEN OwnerId = 5 THEN 'Servicing'
WHEN OwnerId = 6 THEN 'UnitTest'
WHEN OwnerId = 7 THEN 'WebAccess'
WHEN OwnerId = 8 THEN 'ProcessTemplate'
WHEN OwnerId = 9 THEN 'StrongBox'
WHEN OwnerId = 10 THEN 'FileContainer'
WHEN OwnerId = 11 THEN 'CodeSense'
WHEN OwnerId = 12 THEN 'Profile'
WHEN OwnerId = 13 THEN 'Aad'
WHEN OwnerId = 14 THEN 'Gallery'
WHEN OwnerId = 15 THEN 'BlobStore'
WHEN OwnerId = 255 THEN 'PendingDeletion'
END,
SUM(CompressedLength) / 1024.0 / 1024.0 AS BlobSizeInMB
FROM tbl_FileReference AS r
JOIN tbl_FileMetadata AS m
ON r.ResourceId = m.ResourceId
AND r.PartitionId = m.PartitionId
WHERE r.PartitionId = 1
GROUP BY OwnerId
ORDER BY 2 DESC

寻找

Owner           BlobSizeInMB
CodeSense       264426.749071121093
VersionControl  8728.462930678710
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

虽然 VersionControl = 8GB 似乎完全符合我们的代码要求，但 CodeSense 却非常大。我还没有在任何地方找到有关该功能的信息，或者如何禁用它。请帮忙！

PS：如果它与 VS 中的 CodeLens 功能相关，我们也不会使用它。

答案1

这个功能叫做 CodeIndex，这就是我之前找不到它的原因。

以下是配置所需的所有信息：https://docs.microsoft.com/en-us/visualstudio/ide/codeindex-command?view=vs-2015

我把它关掉了，现在我正试图销毁索引，但它出错了

TF246018: 数据库操作超出了超时限制，已被取消。请验证该操作的参数是否正确。

但那是另一个问题……

编辑：事情是这样的。我检查了应用程序层的事件查看器，发现超时的原因如下：

EXEC CodeSense.prc_DeleteAggregates @partitionId=1

我检查了 SP，它正在做三件事

  • 不执行任何操作的调用prc_iPrepareExecution：RETURN 0
  • [CodeSense].[tbl_AggregatorInputQueue]从 1 的位置删除@partitionId。该表是空的，因此无需执行任何操作。
  • [CodeSense].[tbl_AggregateMap]从1开始删除@partitionId。我查询了数据库，发现没有其他分区 ID 的行。此外，aSELECT COUNT(*)需要 5 分钟以上才能完成，所以我取消了它，然后我突然意识到：我可以简单地截断表，因为在我的例子中唯一的分区 ID 是 1。这使我免于用大量无用的事务日志堵塞磁盘并批量删除内容。

果然，我截断了它，但由于种种原因，我又重新运行TFSConfig CodeIndex /destroyCodeIndex了我的收藏，这次它成功了。

然而，当我回到数据库层来恢复现在可能为空的空间时：它还没有空闲。

我回到事件日志并发现EXEC CodeSense.prc_DeleteOrphanedFiles @partitionId=1,@createdBefore=03/17/2019 21:05:28这次超时了！

此 SP 在内存中创建一个表，记录要删除的内容，然后删除它们。我创建了此 SP 的一个副本，并使用TOP 100000子句限制一次删除的行数，并多次运行该副本，直到删除了 200 多万行。

然而，在某些时候，必须有其他东西负责清理桌子tbl_FileReference，tbl_FileMetadata尤其是tbl_Content。

我发现了一个博客文章建议先运行 EXEC prc_CleanupDeletedFileContent 1 一次，然后再 EXEC prc_DeleteUnusedFiles 1, 0, 100000运行多次。

25 分钟后，CodeSense 斑点完全消失

Owner           BlobSizeInMB
VersionControl  8728.347916602539
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

然而，tbl_Content仍然很大，查询仍在运行

我将等待一天左右，看看情况是否有所改善或者是否必须继续挖掘。

编辑2：已经过去了 24 多个小时，查询仍在运行。运行诊断查询告诉我tbl_Content确实在缩小，当我使用 SQL Management Studio 中的“缩小文件”选项时，数据文件开始有更多的可用空间，所以它正在工作！

由于数据库日志文件没有增长并且一切看起来都很稳定，我想我只需要等到查询完成其工作，重新运行它以获得良好的效果，然后继续在数据库级别恢复未使用的空间。

如果您也处于同样的情况，祝您好运。

相关内容