We have a TFS2010 environment. The size is growing every week for a long time now.
We deleted a lot of old branches and team projects. We also used the test attachm
After viewing unreasonable growth of the transaction log of the TFS database I couldn’t find the exact cause of the growth and couldn’t also control automatically shrinking of the log.
Similar solution without the full database backup
I tried this script several days on non-production server and only after i switched to production server.
Ruining on SQL server 2012 & TFS 2015
the following script automatically shrink the transaction log.
Run this script after full back up using the SQL job
Scripts parts:
1) Disconnect all connection to specific database
2) Switch Backup model to simple
3) Set database log size to unlimited
4) Shrink log file to 200mb (or any size you wish)
5) Set max size to 50000 (or any size you wish)
6) Set Backup model to full
Script run takes about 3 -5 seconds on a 140GB DB
USE [master]
GO
ALTER DATABASE [Tfs] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE [Tfs] SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE [Tfs] MODIFY FILE ( NAME = N'Tfs_log', MAXSIZE = UNLIMITED)
GO
USE [Tfs]
GO
DBCC SHRINKFILE (N'Tfs_log' , 200)
GO
ALTER DATABASE [Tfs] MODIFY FILE ( NAME = N'Tfs_log', MAXSIZE = 50000)
USE [master]
GO
ALTER DATABASE [Tfs] SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE [Tfs] SET MULTI_USER
GO
Most of the disk space in your case will be used by the transaction log file, not the data file.
The query above shows only the disk space used by the data file.
You may look at shrinking the transaction log if it has available space.
One more advice I found when faced with a similar problem is to prevent the LDF file from growing back by changing the recovery mode of the table to 'simple'.
First of all, shrink the LDF file. I did it using the SQL management studio.
After shrinking the DB and making sure the TFS still works, follow the instructions here: stop-sql-server-transaction-log-ldf-files-from-growing-indefinitely.
This will cause the SQL server to reduce the amount of recovery data that is being saved to the transaction log so that you won't need to repeat the shrink operation every X month.