web-dev-qa-db-ja.com

tfsbuild.exe delete / destroyは、孤立したものをデータベースに保持します

2013年からTFS2012を使用しています。その間に、データベースは最大60GBまで増加しました。これには、バックアップ時間の増加、ドライブスペースの浪費など、いくつかの欠点があります...

「トップテーブル別のディスク使用量」レポートを調べた後、tbl_BuildInformationテーブルが爆破されました。 60GBのうち46GBは、過去のビルド情報（ビルドログなど）の保存/アーカイブに使用されます。そして、私たちはもはやこの情報を使用する目的はまったくありません。

したがって、MSDNフォーラムの提案に従って、これらをどのようにクリーンアップするかを説明しました。 2つのコマンドを適用しました（tfsbuild.exe delete ...およびtfsbuild.exe destroy ...）TFSサーバーに。ほぼ1.5時間後、クリーンアップは正常に実行されました。ただし、尊重するテーブルは変更されていません。しかし、ほとんどすべてのエントリは孤立しており、それ以上の情報は参照されていません。

他のソースに関しては、この動作は一般的で意図されています。しかし、私の意見では、まったくナンセンスで役に立たない。クリーンで縮小されたデータベースを取得するために、この手順を実行しました。

これを取り除く方法についてのアイデアや推奨事項はありますか？実際、SQLクエリを使用してデータベース内の孤立したエントリを削除することはできますが、専門家は予期しない動作に関して厳密にアドバイスします。あなたの経験は何ですか？

databaseteam-foundation-servercleanuporphans
1
dannyyy

「ビルド情報クリーンアップジョブ」が実行されるまで待つ必要があります（デフォルトでは2日ごとに実行されます）。これは、TFSBuild.exe deleteおよびTFSBuild.exe destroyを実行した後にtbl_buildInformationをクリーンアップするジョブです。

（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 詳細については。

2
Glad