主页 / server / 问题 / 958090
Accepted
Jorge Yanes Diez
Asked: 2019-03-14 06:02:02 +0800 CST

TFS 2015 CodeSense 清理

  • 772

我最近接手了管理 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功能有关，我们也没有使用它。

team-foundation-server

1 个回答

  1. Best Answer

    该功能称为 CodeIndex，这就是为什么我之前找不到它的原因。

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

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

    TF246018: 数据库操作超过超时限制并已被取消。验证操作的参数是否正确。

    但这是另一个问题...

    编辑：这就是发生的事情。我检查了应用层上的事件查看器，发现这是超时的原因：

    EXEC CodeSense.prc_DeleteAggregates @partitionId=1

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

    • prc_iPrepareExecution什么都不做的调用：RETURN 0
    • Delete from [CodeSense].[tbl_AggregatorInputQueue]where @partitionIdis 1. 该表是空的，因此无事可做。
    • [CodeSense].[tbl_AggregateMap]从哪里删除@partitionId1。我查询了数据库，发现没有任何其他分区 id 的行。此外， aSELECT COUNT(*)需要 5 多分钟才能完成，所以我取消了它，然后我突然意识到：我可以简单地截断表，因为在我的情况下唯一的 partitionId 是 1。这使我免于用大量无用的事务日志堵塞磁盘并批量删除内容。

    果然，我把它截断了，但出于好的衡量，我重新运行TFSConfig CodeIndex /destroyCodeIndex了我的收藏，这次它奏效了。

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

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

    该 SP 正在创建一个表来存储要删除的内容，然后将其删除。我用一个子句创建了这个 SP 的副本，TOP 100000以限制一次删除的行数，并运行了几次，直到它摆脱了 2M+ 行。

    但是，在某些时候，必须有其他东西负责清理表tbl_FileReference，tbl_FileMetadata尤其是tbl_Content.

    我发现一篇博客文章建议运行 EXEC prc_CleanupDeletedFileContent 1 一次，然后 运行EXEC prc_DeleteUnusedFiles 1, 0, 100000几次。

    25 分钟后，CodeSense blob 完全消失

    Owner           BlobSizeInMB
VersionControl  8728.347916602539
TeamTest        477.505887984375
ProcessTemplate 2.953623771484
FileContainer   0.024445533203

    但是，tbl_Content仍然很大并且查询仍在运行

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

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

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

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

    • 2

相关问题