[英]Migrating from TFS to VSTS - Reducing TPC Database Size
我們正計划很快從本地TFS實例遷移到VSTS。 在遷移之前,我們運行必備的Validation任務,並獲得了有關TPC數據庫大小的以下輸出報告:
“數據庫當前為191GB。這比使用DACPAC導入方法的建議大小大150GB。當前最大表大小為172GB。這比使用DACPAC導入方法的建議大小大20GB。
驗證完成,“驗證集合數據庫大小”,結果為警告,消息最大表大小當前為172GB。 這比使用DACPAC導入方法時建議的20GB大小要大。”
因此,我們渴望減少TPC數據庫的大小,並且有兩個主要考慮因素:
收縮數據庫並從結果輸出生成DACPAC。
刪除以下任何未使用或冗余的對象:
a)較舊的工作空間
b)建立結果
c)冗余團隊項目
d)未使用的文件
e)在測試運行期間創建的測試附件
f)XAML構建
因此,不勝感激關於這兩種方法的優缺點的一些建議或反饋,建議您這樣做。
鑒於您需要將最大的表減少150GB,我想知道DACPAC是否會成為一個選擇。 也就是說,清理您的TFS實例始終是個好主意。 除非您設法剝離足夠的數據以實際從縮減中獲得任何收益,否則第一步將無濟於事。
您確定的操作確實會有所幫助, 大多數操作已在此處記錄 。 這份最新的支持通知單中還可以找到有助於檢測您的空間分配位置的查詢。
刪除工作區和架子集可以大大減少遷移和升級時間。 您可以使用tf
命令行,也可以利用TFS SideKicks之類的工具來識別和刪除這些文件。
不僅是構建結果,而且經常被忽略,實際的構建記錄會占用大量數據。 使用tfsbuild destroy
(XAML)永久刪除構建記錄。 過去,我遇到過一些客戶,他們的數據庫中有180萬個“隱藏”構建,並刪除了它們,從而節省了大量的數據。 這些記錄保存在倉庫中。
當然,銷毀舊團隊項目可能會返回很多數據。 您不需要發送給天藍色的任何幫助。 您也可以考慮拆分集合 ,而放棄舊項目。 如果您再次需要該數據,則可以選擇分離該集合並將其存儲在某個位置。
刪除的分支是非常常見的隱藏大小豬。 在TFVC中刪除內容時,它們實際上並沒有被刪除,只是被隱藏了。 查找已刪除的文件,尤其是舊的開發或功能分支可以為您提供很多數據。 使用tf destroy
擺脫它們。
您可能還希望在nuget軟件包文件夾中查找已簽入的文件夾,這些文件夾也可以迅速占用大量空間。
哦,是的,尤其是當您使用測試附件時,這些附件可能會變得瘋狂起來,具體取決於您的TFS版本是使用內置的測試附件清理功能還是使用TFS電動工具中的“ 測試附件清理器” 。
構建定義本身不會占用大量的數據庫空間,但是構建結果可能會占用很多。 但是上一節已經介紹了這些內容。
由於強制推送或刪除分支,您可能無法再訪問git存儲庫中的數據。 Git中的某些數據也可能會更有效地打包。 要清理您的存儲庫,您必須在本地克隆它們,清理它們,從TFS中刪除遠程存儲庫,然后將清理后的副本推送到新的存儲庫中(您可以使用與舊存儲庫相同的名稱)。 這樣做將破壞現有構建定義的引用,您將必須對其進行修復。 在使用時,您還可以運行BFG repo Cleaner並轉換存儲庫,以使Git-LFS支持能夠更優雅地處理存儲庫中的大型二進制文件。
git clone --mirror <<repo>>
# optionally run BFG repo cleaner at thi s 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 ites)也可以刪除。 我的同事Rene有一個很好的工具,可讓您通過首先創建適當的工作項查詢來進行銷毀 。
TFS通常不會直接從數據庫中刪除數據,在許多情況下,它只是將內容標記為已刪除,以進行最新處理。 若要強制立即進行清除,請在Project Collection數據庫上運行以下存儲過程:
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
為了確定每個部分中存儲了多少數據, 您可以使用一些有用的查詢 。 實際查詢取決於您的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
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.