
私たちは 2013 年から TFS 2012 を使用しています。その間に、データベースは最大 60 GB まで増加しました。これにより、バックアップ時間の増加、ドライブ領域の浪費など、いくつかの欠点があります。
「上位テーブルによるディスク使用量」レポートを調べたところ、tbl_BuildInformation
テーブルが膨張していることがわかりました。60 GB のうち 46 GB は、過去のビルド情報 (ビルド ログなど) を保存/アーカイブするために使用されています。この情報を今後使用する目的はまったくありません。
そのため、MSDN フォーラムの提案に従って、これらをクリーンアップする方法を試しました。TFS サーバーに 2 つのコマンド (tfsbuild.exe delete ...
とtfsbuild.exe destroy ...
) を適用しました。約 1.5 時間後、クリーンアップは正常に完了しました。ただし、関係するテーブルは変更されていません。ただし、ほとんどすべてのエントリは孤立しており、これ以上の情報への参照はありません。
他のソースに関しては、この動作は一般的であり、意図されたものです。しかし、私の意見ではまったく無意味であり、役に立たないものです。クリーンで縮小されたデータベースを取得するために、この手順を実行しました。
これを解決する方法についてのアイデアや推奨事項はありますか? 実際には、SQL クエリを使用してデータベース内の孤立したエントリを削除できますが、専門家は予期しない動作が発生する可能性があるため、これを絶対に行わないようアドバイスしています。皆さんの経験を教えてください。
答え1
TFSBuild.exe delete
「ビルド情報のクリーンアップ ジョブ」が実行されるまで待つ必要があります (デフォルトでは 2 日ごとに実行されます)。これは、およびを実行した後に tbl_buildInformation をクリーンアップするジョブですTFSBuild.exe destroy
。
スケジュールは (PowerShell で) 次のように確認できます:
$collection = "http://yourservername:8080/tfs/YourCollection" # change this to the URL of your team project collection
$pathToAss2 = "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0"
$pathToAss4 = "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v4.5"
Add-Type -Path "$pathToAss2\Microsoft.TeamFoundation.Client.dll"
Add-Type -Path "$pathToAss2\Microsoft.TeamFoundation.Common.dll"
Add-Type -Path "$pathToAss2\Microsoft.TeamFoundation.WorkItemTracking.Client.dll"
Add-Type -Path "$pathToAss2\Microsoft.TeamFoundation.VersionControl.Client.dll"
Add-Type -Path "$pathToAss4\Microsoft.TeamFoundation.ProjectManagement.dll"
$tpc = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($collection)
$jobService = $tpc.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationJobService])
$job = $jobService.QueryJobs() | Where-Object {$_.Name -eq "Build Information Cleanup Job"}
$job
$jobService.QueryLatestJobHistory([Guid[]] @($job.JobId))
ジョブをすぐに実行するためにキューに入れるには、前のコマンドの後に次のコマンドを実行します。
$jobService.QueueJobNow([Guid] $job.JobId, $false)
スケジュールを変更するには、次のコマンドを実行します。
$interval = 172800 # change this to the number of seconds between each run; 172800 = 2 days
$job.Schedule[0].Interval = $interval # there is only one schedule for the build information clean-up job, we set its interval
$jobService.UpdateJob($job)
このジョブの次の実行がいつスケジュールされているかを実際に確認するには、DB に移動して次のクエリを実行する必要があります (このクエリは、列「ScheduledTime」と「Interval」にリストされているすべてのコレクションの Tfs_YourCollection の情報が表示されるため、完全に正しいわけではありませんが、その他の情報、特に QueueTime は正しいです)。
USE Tfs_YourCollection
SELECT S.JobId, D.JobName, S.ScheduledTime, S.Interval, CQ.QueueTime, SH.Name
FROM tbl_JobSchedule S
LEFT OUTER JOIN tbl_JobDefinition D ON D.JobId = S.JobId
LEFT OUTER JOIN [Tfs_Configuration].dbo.tbl_JobQueue CQ ON CQ.JobId = S.JobId
LEFT OUTER JOIN [Tfs_Configuration].dbo.tbl_ServiceHost SH ON SH.HostId = CQ.JobSource
WHERE D.JobName = 'Build Information Cleanup Job'
見るhttp://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspxそしてhttp://blogs.msdn.com/b/granth/archive/2013/02/13/tfs2012-what-are-all-the-different-jobs-built-in-to-tfs.aspx詳細については。