2

我的本地 Azure DevOps 2019 备份显示 .mdf 文件的大小不可持续地增加

  • query1 显示它是“dbo.tbl_content”表
  • query2 显示它是 112GB 的“FileContainer”。
  • query3 显示它的 pipelines://b 为 93GB。
  • query4 显示使用的大小已从每月 1GB 增加到每月无法承受的 10GB。这发生在 2020 年 1 月，可能巧合的是，我们从 TFS18 升级到了 AzureDevOps19。

所以，我相信我正在寻找需要清理的构建管道（而不是发布管道）？从历史上看，我们曾尝试保留 366 天的旧构建日志，但按照我们的速度，我们不会成功。

我们有大约 40 个构建管道（一些历史性的，不再运行），inc 4 在提交时触发（CI）。

回复：保留政策...

  • 典型的 CI 构建保留策略。保留天数：10 分钟保留：1
  • 典型的 RC 构建保留策略。保留天数：180 分钟保留：50
  • 来自：DefaultCollection/Base/_settings/buildqueue... 最长保留策略/保留天数：183 最少保留：55 默认保留策略/保留天数：15 最少保留：1 永久销毁构建/保留构建记录后的天数删除：366 <-我昨天从7000减少了这个

任何帮助在这里表示赞赏，但特别是：

  • 如何追踪导致问题的特定构建？我该如何解决？

  • 是否有任何工具可以告诉我问题所在。比如TFS曾经有一个健康审计工具，但是我看不到？

    query1 SELECT TOP 10 o.name, SUM(reserved_pa​​ge_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_pa​​ge_count) DESC

    query2 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 '服务' 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

    query3 SELECT CASE WHEN Container = 'vstfs:///Buil' THEN 'Build' WHEN Container = 'vstfs:///Git/' THEN 'Git' WHEN Container = 'vstfs:///Dist' THEN 'DistributedTask' WHEN Container = 'vstfs:///Rele' THEN 'Release' ELSE Con​​tainer END AS FileContainerOwner, SUM(fm.CompressedLength) / 1024 / 1024 AS TotalSizeInMB FROM (SELECT DISTINCT LEFT(c.ArtifactUri, 13) AS Container, fr.ResourceId , ci.PartitionId FROM tbl_Container c with (nolock) INNER JOIN tbl_ContainerItem ci ON c.ContainerId = ci.ContainerId AND c.PartitionId = ci.PartitionId INNER JOIN tbl_FileReference fr ON ci.fileId = fr.fileId AND ci.DataspaceId = fr。 DataspaceId AND ci.PartitionId = fr.PartitionId) c INNER JOIN tbl_FileMetadata fm ON fm.ResourceId = c.ResourceId AND fm.PartitionId = c.PartitionId GROUP BY c。按 T​​otalSizeInMB DESC 排序的容器

    query4 选择 DATEPART(yyyy, CreationDate) as [year], DATEPART(mm, CreationDate) as [month], SUM(DATALENGTH(Content)) / 1048576 as [Size in Mb] From tbl_Content With (nolock) Group by DATEPART(yyyy , CreationDate), DATEPART(mm, CreationDate) Order by DATEPART(yyyy, CreationDate), DATEPART(mm, CreationDate)

相关问题：TFS2015 tbl_Content 增加

4

1 回答 1

1

您可以尝试运行以下查询以缩小日期：

SELECT ci.ContainerId,
c.ArtifactUri,
c.Name,
c.DateCreated,
SUM(fm.FileLength)
FROM tbl_ContainerItem ci
JOIN tbl_FileReference f
ON f.FileId = ci.FileId
JOIN tbl_FileMetadata fm
ON fm.PartitionId = 1
AND fm.ResourceId = f.ResourceId 
LEFT JOIN tbl_Container c 
ON c.ContainerId = ci.ContainerId 
AND c.PartitionId = 1 
WHERE f.PartitionId = 1 
AND ci.PartitionId = 1 
GROUP BY ci.ContainerId, c.ArtifactUri, c.Name, c.DateCreated

由于它与构建有关，请检查测试报告是否导致此问题。您可以参考此线程中的详细操作：TFS 数据库增长太大

此外，您还可以尝试缩减 TFS/Azure DevOps 数据库中的事务日志。

于 2020-05-29T08:47:23.140 回答