I have the following problem with Team Foundation Server Express 2015.
I ran out of SQL Database Space. So I cleaned up a littlebit and used TFS Destroy to permanently delete some larger files from source control.
I expected that the Size auf the table dbo.tbl_Content would get less after some time. But the opposite happened. 3000 Entries where added to the table and it got larger.
How can I cleanup TBL_Content from old files that have been destroyed already?
The TBL_Content Table has now 8.8 GB.
Executing stored procedures like prc_DeleteUnusedContent and [dbo].prc_DeleteUnusedFiles did not help at all.
Orphan data still leaves after running the tf destroy command, and will be deleted later by a TFS Background job agent. That is the reason why table dbo.tbl_Content size doesn't drops.
Here are some steps you can try to reduce the size of TFS databases:
1). Download and install TFS2015 Power Tool to get the Test Attachment Cleaner to remove large test attachments:
Tcmpt.exe attachmentcleanup /collection: TeamProjectCollectionUrl /teamProject: TeamProject /settingsFile: SettingsFilePath [/outputFile: ReportFilePath] [/mode: Preview/Delete]
2). Remove old workspaces which is no longer used for long time.
3). Delete old unused team projects: https://msdn.microsoft.com/en-us/library/ms181482(v=vs.140).aspx
Related
We have been using the old style (XAML) of builds until a month ago and then started using vNext builds. After that I noticed that tbl_Content table in TFS database started growing really fast. For instance, in the last 8 hours it grew 10 GB and I can't figure out what why it is doing that. Does any one know what it is?
The reason I am saying it is the vNext build is because I noticed it started growing after we upgraded, but I way be wrong. I hope it is not trying to store my build output or something like that. Is there way to know what is in the tbl_Content table? Can they be deleted? Or is there way to delete some things from that table without messing up TFS?
TFS Databases grows for all sorts of reasons. Some common sources of
runaway growth include using build or release automation without
configuring appropriate retention policies, creation of a
small number of very large items (work items, version control files,
etc.) by humans or tooling, and so forth. We have work on the backlog
to make the distribution of space in TFS databases more discoverable.
You could try to use a sql script such as below to show a increase of the tbl_Content over the last months:
select DATEPART(yyyy, CreationDate) as [year],
DATEPART(mm, CreationDate) as [month],
count(*) as [count],
SUM(DATALENGTH(Content)) / 1048576.0 as [Size in Mb],
(SUM(DATALENGTH(Content)) / 1048576.0) / count(*) as [Average Size]
from tbl_Content
group by DATEPART(yyyy, CreationDate),
DATEPART(mm, CreationDate)
order by DATEPART(yyyy, CreationDate),
DATEPART(mm, CreationDate)
It's able to know to look at the distribution of "owners" for the data in tbl_Content through a SQL query. Detail steps please refer Aaron Hallberg's reply in this similar question: TFS Database size
To reduce the size of the tbl_Content table, you could refer to this blog: TFS tbl_Content Table and Database growth out of control,it can be summed up in three steps in general:
Clean some old workspaces that you doesn't need any more.
Run the tf destory command to delete those unnecessary source files permanently.
Using TFS power tool to clean Test attachments and test results.
I was googling around and tried doing all kinds of things to see what is making the problem. Other problem is there is no documentation about the TFS database schema. After spending almost 10 hours with playing with TFS Database I almost become a TFS DB pro. Querying around the tbl_Content, tbl_FileMetadata and tbl_FileType helped me little to figure what exactly is making the problem.
So at the end removing the /v:diag from MSBuild arguments fixed my issue. I am not sure what all it was putting to the database, but each build was adding close to 1GB data to the database.
We develop every US and Bug on a branch to be able to review the code related with that element so we generate a nice amount of branches. Every month we delete the old ones and traditionally this process has been way too slow.
We can only commit the deletion of 6 to 10 branches at once, otherwise we get a timeout. The deletion of 10 branches takes more that 5 minutes.
We have migrated recently from TFS 2010 and VS 2010 to TFS 2015 and VS2015 and nothing changed.
Is this normal? Is there a way to speed up this? Looking for an answer in google all I found is something related with local workspaces which is not the case, the workspace is remote.
Regards.
First, please check if other operations also delay so long, like adding a file, are fast.
And you could use tf delete command instead of GUI in VS. Which may do the trick. Deleting the branch will only actually perform a "soft delete". The branch will still exist complete with all of it's history, except it will be hidden. If you want to permanently deletes version-controlled files from Team Foundation version control, need to perform a tf destroy command.
Also check if it's a client issue, like a conflicting Visual Studio add-in. Try to clear TFS and VS cache.Besides, you could use another account and machine to do the delete operation next month.
Must to say there is some delay of deleting branch in TFS using VS GUI. I have created 20 empty branches for test. It took about 30 seconds to complete the whole delete operation. So if your branch have a number of folders with a large number of files, then the deletion of 10 branches takes about 5 minutes looks like acceptable. After all in TFVC, we don't create and delete branches frequently like GIT.
Is it possible to archive old data from MS Team System Source Control? We have up to 10,000 changesets in our TFS database, and are unlikely ever to want to go that far back, but the database files are getting ever larger. Is it possible to archive everything before a certain date (say) to reduce the size of the database? if not, taken to its logical conclusion a long lived actively developed project will eventually explode.
You can back up the whole TFS database and then use destroy command to permanently delete the source control tree. But you can do that only for whole source control paths, not specific versions.
In case there are many deleted files you can also use the same command to review the source control tree and permanently destroy these deleted files.
You will not be able to just delete old changesets because TFS stores incremental changes every time you check-in. This also implies that maybe you have large binary files stored in TFS - files larger than certain limit are not stored incrementally (thus saving space) but instead every version is stored complete.
Documentation on the command: http://msdn.microsoft.com/en-us/library/bb386005(v=vs.100).aspx
I'm using TFS 2012 (Free preview).
I have a bunch of projects in my solution under source control.
Sometimes I find it the easiest solution to a problem to just scrap an entire project and start over. However, everytime I do that I run into trouble because the "deleted" project stays in the Source Control Explorer with a "deleted" status (Show/Hide Deleted Items button) and, at best, sticks around as junk, and at worst leads, to conflicts later on.
How can I get all traces of them removed?
You can use the tf destroy command. This is non recoverable.
TFSDeleteProject permanently destroys the team project, after which it cannot be recovered.
TFSDeleteproject [/q] [/force] [/excludewss] /collection:URL TeamProjectName
Does the delete shelveset operation reclaim space used by the changeset in tfs database?
I don't want to know the details, just want to know - will the space be reclaimed, or the database will grow, if i create and delete many big shelvesets?
Shelvesets are essentially uncommitted pending changes with a special flag set that identifies them as a shelveset rather than a normal workspace.
When you delete a shelveset, the pending changes are undone and the content is flagged for removal.
If the shelveset is quite large and you were hoping to free up disk space on your server, you should know that the space won't immediately be released back to SQL, but it will eventually be. At a high-level, the following things have to happen:
TFS has a built-in job (Version Control Administration Job) that runs nighlty and clears up destroyed content.
There is another job (Optimize Databases) which will reorganize/rebuild SQL indexes
SQL will also need to run it's "ghost cleanup" process to release the pages
Unless you shrink the SQL data files, SQL will retain the space as 'free pages' and not return it to the operating system.
The spaced used by the shelveset will be reclaimed when deleted. Shelvesets are like workspaces on the server and when you delete the shelveset the corresponding rows are deleted.