我正在使用 Azure DevOps Server（本地）v2020 更新 1.2 (v18.181.32404.7)
我们正准备迁移到 Azure DevOps 服务（云），但我们的数据库很大，我们正在努力清理它。
TL;DR：表中有近 60 GB 的测试附件tbl_Content，尽管表中没有相应的记录，但其中许多附件仍然存在Build.tbl_Build。
查看项目集合的数据库，tbl_Content它是迄今为止最大的 - 占用约 110 GB。我运行了以下查询，将“team test”标识为近 60 GB 的所有者：
SELECT SUM(m.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
AND OwnerId = 4
该查询的结果：
我制作了一个查询，它将显示特定构建的附件（内容）。下面是一个示例，我在其中运行构建 64447 的查询，该构建属于 ID=600 的构建定义：
SELECT
r.FileId,
r.ResourceId,
r.CreationDate,
a.FileName,
bc.BuildUri,
bc.BuildId,
bc.BuildNumber,
bc.BuildDefinitionId,
bd.DefinitionName,
r.DeletedOn,
b.BuildId as BuildIdFromBuildTable,
CompressedLength / 1024.0 / 1024.0 AS BlobSizeInMB
FROM tbl_FileReference AS r
LEFT JOIN tbl_FileMetadata AS m
ON r.ResourceId = m.ResourceId
AND r.PartitionId = m.PartitionId
left join tbl_Attachment a on r.FileId = a.TfsFileId
left join tbl_TestRun tr on a.TestRunId = tr.TestRunId
left join [tbl_BuildConfiguration] bc on tr.BuildConfigurationId = bc.BuildConfigurationId
left join Build.tbl_Definition bd on bc.BuildDefinitionId = bd.DefinitionId
left join tbl_Content content on content.ResourceId = r.ResourceId
left join Build.tbl_Build b on b.BuildId = bc.BuildId
WHERE r.PartitionId = 1
AND OwnerId = 4
AND BuildDefinitionId = 600
AND bc.BuildId = 64447
ORDER BY r.CreationDate DESC
这给了我一堆如下所示的记录：
因此，我可以看到这些附件记录确实存在，并且占用了 中的空间tbl_Content，但是因为该BuildIdFromBuildTable列显示了 a NULL，所以我们可以看到表中没有 ID 为 64447 的任何构建的记录Build.tbl_Build（我还检查了dbo.tbl_Build只是为了安全的）。
因此，看起来即使该构建不久前被删除，该构建的附件仍然存在，并且占用了我们的 TFS DB 中的许多 GB 数据。
我尝试tfsbuild destroy在正确的项目和围绕此构建日期的日期范围的集合上运行命令，但它表示未找到已删除的构建。
我怎样才能摆脱大量孤立的构建附件数据？