Git 从TFS迁移到VSTS-需要对dbo.tbl_内容执行操作

我们正在计划很快从本地TFS迁移到VST。在迁移之前，我已经运行了先决条件验证任务，并获得了一条警告，当前TPC数据库大小超过了DacPac的最大限制

下面提供了数据库验证的一个片段：

The full database size is       187411 MB.
The database metadata  size is   28145 MB.
The database blob size is       159266 MB.
The top 10 largest tables are:

===================================================
Table name                               Size in MB
dbo.tbl_Content                          168583
dbo.tbl_BuildInformation2                3233

===================================================
The File owners are:
===================================================
Owner                                    Size in MB
Build+Git                                67410
TeamTest                                 59261
VersionControl                           18637

从上面可以明显看出，dbo.tbl_Content表是导致数据库大小过大的主要原因，从VSTS操作的角度来看，Build+Git和TeamTest是主要原因。因此，我的意图是将重点放在上述对象上，以便对任何数据库进行清理以减小大小

---

问题是，我如何在上述三个对象（dbo.tbl_Content、Build+Git和TeamTest）上以最有效和最好的方式实现这一点？

我写了一篇关于导入前清理TFS的所有方法的博文：

但请记住，有一个备用路径需要在Azure中安装临时IaaS服务器，并在其上安装SQL server和TFS/Azure DevOps服务器。这条路可能比试图清理你所拥有的东西更简单、更快，并且同样受到支持

摘录如下：

若要为迁移准备TFS项目集合，可能需要先删除过时的旧数据以减小数据库大小

这里已经记录了大多数操作。可以帮助检测空间分配位置的查询也可以在最近的支持通知单中找到

删除旧工作区 删除工作区和搁置集可以大大减少迁移和升级时间。使用tf命令行或利用TFS SideKicks之类的工具来识别和删除这些命令行

构建结果 不仅是构建结果，而且经常被忽略的实际构建记录可能会占用大量数据。使用tfsbuild destroy XAML永久删除生成记录。在过去，我遇到过一些客户，他们的数据库中有180万个隐藏版本，删除它们会删除相当多的数据。这些记录保存在仓库里

如果您在执行tfsbuild时遇到非常慢的情况，那么对于系统中的每个构建，都只是为了获得构建ID

旧团队项目 当然，销毁旧的团队项目可以返回大量数据。任何您不需要发送到azure的内容都会有所帮助。你也可以考虑拆分收集和遗留旧项目。如果您再次需要该数据，您可以选择分离该集合并将其存储在某个位置

冗余文件 删除的分支是一种非常常见的隐藏大小限制。在TFVC中删除内容时，它们实际上并没有被删除，只是被隐藏了。查找已删除的文件，尤其是旧的开发或功能分支，可以返回大量数据。使用tf销毁来清除它们

您可能还需要查找签入的nuget软件包文件夹，这些文件夹也会很快占用大量空间

编码透镜索引

Team Foundation Server 2013引入了TFVC控制文件的服务器端索引，以允许VisualStudio访问WHO上直接在UI中更改哪些文件的数据。这个服务器端索引可以根据代码库和用户数量的大小快速增长

您可以通过tfsconfig codeindex命令控制索引。您可以指定要在多长时间之前建立索引/indexHistoryPeriod:months、完全删除索引/destroyCodeIndex或排除特定的问题文件/ignoreList:add$/path

代码镜头在产品内部也被称为代码感知和代码索引

如果删除索引超时。请小心，不支持在TFS集合数据库上手动运行SQL

测试附件 Ohh是的，特别是当您使用测试附件时，这些附件可能会疯狂增长，具体取决于您的TFS版本，可以使用内置的测试附件清理功能，也可以使用TFS电动工具中的测试附件清理器

XAML构建 构建定义本身不会占用大量数据库空间，但构建结果可能会改变。但是这些已经在前面的章节中介绍过了

在过去，我必须对tfbuid.exe进行修补，以处理大量的生成记录，因为它倾向于在继续执行删除操作之前尝试在本地获取所有生成数据。您可能需要依赖TFS客户机对象模型来实现类似的结果

Git存储库 您的git存储库中可能有由于强制推送或删除分支而无法访问的数据。Git中的某些数据也可能被更有效地打包。要清理存储库，您必须在本地克隆它们，清理它们，从TFS中删除远程repo，并将清理后的副本推送到新存储库，您可以使用与旧存储库相同的名称。这样做会破坏现有构建定义的引用，您必须修复这些引用。虽然 您已经做到了，还可以运行并转换存储库，以使Git LFS支持更优雅地处理存储库中的大型二进制文件

git clone --mirror https://tfs/project/repo
# optionally run BFG repo cleaner at this point
git reflog expire --expire=now --all 
git gc --prune=now --aggressive
git repack -adf
# Delete and recreate the remote repository with the same name
git push origin --all
git push origin --tags

工作项附件 工作项可以收集大量数据，尤其是当人们开始将大型附件附加到工作项时。您可以使用witadmin destroywi删除附件过大的工作项。要保留工作项但删除其附件，可以从当前工作项中删除附件，然后克隆它。克隆后，销毁旧工作项，以便清理附件

您不再需要的旧工作项（如6年前的sprint项）也可以删除

确保运行清理作业 TFS通常不会立即从数据库中删除数据，在许多情况下，它只是将内容标记为已删除，以便稍后处理。要强制立即进行清理，请在项目集合数据库上运行以下存储过程：

EXEC prc_CleanupDeletedFileContent 1
# You may have to run the following command multiple times, the last
# parameter is the batch size, if there are more items to prune than the 
# passed in number, you will have to run it multiple times
EXEC prc_DeleteUnusedFiles 1, 0, 100000

最后的100000是要处理的标记项目数。如果删除了很多内容，可能需要运行最后一个过程几次，然后才能删除所有内容

其他有用的查询 要确定每个部分中存储了多少数据，可以运行一些有用的查询。实际的查询取决于您的TFS版本，但由于您正在准备迁移，我怀疑您目前使用的是TFS 2017或2018

查找最大的表：

SELECT TOP 10 
    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

查找最大的内容贡献者：

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

如果问题出在文件容器上：

SELECT 
    CASE 
        WHEN Container = 'vstfs:///Buil' THEN 'Build'
        WHEN Container = 'vstfs:///Git/' THEN 'Git'
        WHEN Container = 'vstfs:///Dist' THEN 'DistributedTask'
        ELSE Container 
    END AS FileContainerOwner,
    SUM(fm.CompressedLength) / 1024.0 / 1024.0 AS TotalSizeInMB
FROM 
    (SELECT DISTINCT LEFT(c.ArtifactUri, 13) AS Container,
    fr.ResourceId,
    ci.PartitionId
FROM tbl_Container c
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.Container
ORDER BY TotalSizeInMB DESC

---

我的TFS 2015服务器托管了几个GIT存储库，其中一些存储库具有非常大的LFS文件。使用TFS web界面，我删除了一些测试报告，它们占用了tbl_内容中的大量存储空间，我注意到文件并没有从数据库中删除

我几乎什么都试过了。tf delete无效，因为回购已被删除。 存储过程prc_*帮助不大。刚刚将大小从50 GB减少到41 GB

正确清理tbl_内容数据库的唯一方法是执行以下SQL查询：

DELETE FROM tbl_content WHERE ResourceId IN (SELECT A.[ResourceId]  
  FROM [dbo].[tbl_Content] As A
  WHERE A.ResourceId NOT IN (SELECT X.ResourceId FROM tbl_filemetadata as X)
  AND A.ResourceId NOT IN (SELECT Y.ResourceId from tbl_filereference as Y))

这个过程花了半个多小时。之后，我执行了数据库收缩。现在表的大小是17GB

---

现在，我将把所有GIT存储库从TFS移动到自托管Gitea服务器。与贪婪和不可维护的TFS相比，服务器非常轻量级和高效…

最有效和最好的方法是什么？对三个命名对象进行清理-dbo.tbl_Content、Build+Git和TeamTest。感谢Jesse在您的站点和帖子中所做的所有努力，我知道我在过去也找到了它。我现在遇到的是，我的pipelines://b FileContainer的大小增加到了110GB。对于如何将其缩小到一个项目，甚至是最大的构建定义，您有什么建议吗？运行TFS 2019顺便说一句，我已经花了很长时间来研究模式的这一部分。必须有一个可以追溯到项目的标识符，或者，我猜，是构建定义ID。@Nico有一个客户端请求进一步挖掘。。。查询仍然是粗略的，但它聚合到团队项目和Repo/发布定义/构建定义。尚未涵盖所有数据类型，可能需要在野外进行进一步调整。。。谢谢你，杰西！如果你感兴趣，我会帮你写剧本。它运行了11分钟，返回了608行。最大的一行包含项目集和FriendlyName NULL，该行为47GB，显示有487344行。第二行是一个构建定义，它在4834行中声明16GB。空值是预期值还是您可能正在处理的内容？如果您需要和我的数据，请告诉我是否可以提供帮助。@nico我已经实现了一些查找。如果没有更多的数据和对数据库的访问，很难说它为什么返回null。