CODEWITHSUNDEEP
msbuildtfsbuild
xcodr
xcodr

Reputation: 1177

TFS2010 database size

We've been using TFS since around 2009 when we installed TFS2008. We upgraded to TFS2010 at some point and we've been using it for source control, work item management, builds etc.

Our TFSVersionControl.mdf file is 287,120,000 KB (273GB). We ran some queries and found that our tbl_BuildInformationField table is massive. It has 1,358,430,452 rows which takes up 150,988,624 KB (143GB). We have multiple active products over multiple active builds which more than one solution per build and the solutions aren't free of warning messages.

My questions:

  1. Is it possible to stop MSBuild from spamming the tbl_BuildInformationField table so much? I.e. only write errors and general build information and not all the warnings for every project?
  2. Is there a way to purge or clean up old data from this table?
  3. Is 273GB for 4 years of TFS use an average size?
  4. Is 143GB for tbl_BuildInformationField a "normal" size?

Upvotes: 1

Views: 355

Answers (1)

drk
drk

Reputation: 865

The table holds the values and output of build process. Take note that build retention policy doesnt actualy delete the build object like everything else in TFS the object is marked deleted and only public visibility and drop location is cleared.

I would suggest if you have retainened same build definitions for very long time (when build definition is deleted the related objects get removed as well) you should query for build info including deleted ones using TFS api, the same api will also alow you to remove them for good. Deleting build definitions probably will not work and will fail with timeout error.

You can consult the following: http://blogs.msdn.com/b/adamroot/archive/2009/06/12/working-with-deleted-build-data-in-team-foundation-server-2010-beta-1.aspx

Upvotes: 3

Related Questions