Our TFS database size was growing really quick and I figured out that the issue was with tbl_TestResult table. I am not sure why it is growing that fast. It seems there will be a record for each test case. In my case, we have more than 1000 test cases that will be fired in each check-in. That means we do average 20 check-ins a day. That is around 20,000 records.
My question is can I manually delete the records on that table? Will it make any problems to the TFs other than losing the tests results?
UPDATE:
We have TFS 2015
Deleting data manually or changing the schema in any way would result in your TFS instance no longer being supportable by Microsoft. It effectively invalidates your warranty.
In TFS 2015 you can change the Test Management retention settings in the Team Project admin page. Default is 30 days, but someone may have changed it.
Other than that this is the normal meta data that is collected as part of your ALM/DevOps platform.
**
This was "fixed" in TFS 2017 because they changed the schema for the test results https://www.visualstudio.com/en-us/news/releasenotes/tfs2017-relnotes#test. Brian Harry mentioned a 8X reduction in storage from the new schema https://blogs.msdn.microsoft.com/bharry/2016/09/26/team-foundation-server-15-rc-2-available/
Related
My team works in a 2 week timebox and they indicate how many hrs each PBI, Task, or Bug will take via effort (if PBI) and remaining effort (if Task), and both if a bug.
As they progress through the Sprint they update their hrs. to show progress of effort.
For example, it's July 24 and John knows that updating a module will take 20 hrs. To complete and as he progresses through the Sprint he updates that number to 15, 10, 5, and then eventually 0. My goal is to show a report with that trail to verify that the 20 hrs. committed to the task was completed. I did some research and could not find much help, but perhaps I'm not stating my question right. Any advice regarding this issue would be much appreciated.
What you are looking for is more like a time tracker and generated report to verify or reflect it.
We do not have this kind of build-in feature or report in TFS server. However, as a workaround, there is a number of applications/add-on out there that expose TFS time tracking/time sheet capability.
They offer different levels of integration with TFS depending on your specific workflows/requirements. They pick up your TFS data entries and provide dashboards for operational reports as well as API to get data loaded to your systems.
Some 3rd-party extension for your referenceļ¼
7pace time tracker
SSW Time Pro
I have started using TFS Integration Tools to migrate work items from one TFS2010 project to another team project within the same collection. After some small trial runs and modifications to the field and value mappings I started a migration on our entire product backlog. Approximately 170000 change groups were discovered and analyse started. However, during the analysis the connection to the TFS server was lost so the migration had to be restarted. After the restart approx 340000 change groups were identified (roughly double) without any significant changes being made to work items in the backlog.
Has anyone experienced a similar problem or are aware of settings or changes that can be made in the tool to limit this increase in change groups? The amount of time taken to analyse so many groups is causing the migration to take much longer that was initially expected.
After several runs, I found out that the count appears to be a running total so logically enough when I experienced a break in connection all change groups had to be re-analysed causing the "doubling" in change groups.
i am having a TFS 2012 server for managing my project
i have several sprints with same length 2weeks
Is it possible to set a whole project start and end dates ?how can you see the whole project start and end dates with all the sprints informations weather it is ongoing, finished, late.
Thanks
The sprints should be defined under a parent node. You can set this node's start and end dates just as you would the sprints.
As for seeing information about the project (i.e. whether, or not, it is on-going, finished, late, etc.), depends on which metrics you are looking for. SQL Server Reporting Services contain reports that run off both the Warehouse database and the OLAP cube that resides in Analysis services. The reports are dependent on which process template the project is based off of (Agile, Scrum, CMMI, etc.). Nonetheless, the reports will give you overview information, release burndowns, sprint burndowns, etc.
I'm in the process of setting up a backup plan for a Team Foundation Server. I downloaded Power Tools for TFS and I'm using the Backup Plan Wizard that was included in that pack. I am now at the step where I'm supposed to decide how to schedule the backups and I have no idea what to choose for my setup.
I get what everything means, except Transactional Backup Interval.
I would appreciate suggestions for a good schedule. What I would like to achieve is being able to restore and still look back a few versions, if possible. The minimum backup I would like to have is the latest version.
It might be important to add that I got to choose "Backup retention days" earlier and set that to 30.
The transactional backup interval likely refers to how often transaction logs for your TFS databases are backed up. The schedule you choose will probably depend on how busy your repository is.
At my current client there are six developers, and we share some of the load for source control between VSS and TFS (we're transitioning). Corporate policy says we must backup transaction logs every hour during business hours, and an additional one at midnight. Our local backups are on a four-day retention cycle with off-site backups lasting years.
I would make a decision based on how much work you'd want to lose if your repository was lost and your working copy was destroyed simultaneously (natural disaster?).
My TfsVersionControl database has grown to 40+ GB in size. We recently did a TFS Destroy on a folder tree that should have cleared up at least 10 GB but instead it seemed to have no effect.
When I look at the tables in TfsVersionControl, I am first shocked to see that there are no foreign keys at all in the database. Running a few queries, I see that there is some orphaning going on:
tbl_Content has 13.9 GB of records that don't have a related tbl_File record
tbl_File and tbl_Content have 2.4 GB that don't have a related tbl_Namespace record
The cleanup job seems to be running nightly (prc_DeleteUnusedContent) and running it against the database manually doesn't remove any orphans. I see in the log for the cleanup job that it failed on 3/16, which is the morning after I destroyed the large amount of data. The error was due to a full transaction log.
Could that error be the reason I'm left with all this orphaned data that can't be deleted? How can I permanently destroy this unneeded content?
See the blog post on MSDN
http://social.msdn.microsoft.com/Forums/en-SG/tfsversioncontrol/thread/5f3f8916-1c6d-46f7-9dae-2cdaeaee98db
As noted by Chandru from the TFS team:
This is due to a bug in TFS 2008 - where if the nightly job failed, it caused this problem. Please contact microsoft support and they can provide you a fix for it. Please do not attempt to fix this yourself.
After a long back and forth with the folks at Microsoft, it turns out this is a known bug in the failure of some cleanup processes. There's a knowledge base article here: http://support.microsoft.com/kb/974596
The hotfix described is obsolete if you've already installed TFS 2010.
In addition, the tech at Microsoft had me run a DELETE statement on tbl_Content to delete all records which didn't point to an actual tbl_File record. I'd post the SQL, but don't want to be responsible for anyone copying and pasting. It's pretty self explanatory and as easy as you think.