8

我们有一个 TFS2010 环境。很长一段时间以来，它的大小每周都在增长。

我们删除了很多旧的分支和团队项目。我们还在几个项目中使用了测试附件清洁器，就像 Brian Harry 在他的帖子中所说的那样。http://blogs.msdn.com/b/bharry/archive/2011/10/31/tfs-databases-growth-out-of-control.aspx

数据库并没有变小。我也尝试多次使用 destroy 命令，但没有任何帮助。

我检查了所有我能想到的日志，但找不到任何错误。

有人建议吗？

谢谢

使用评论中询问的查询结果进行编辑：

TableName SchemaName RowCounts TotalSpaceKB UsedSpaceKB UnusedSpaceKB
FieldsDataArchive dbo 0 0 0 0
tbl_AuditLog dbo 41710 5168 3800 1368
tbl_AuthorizationUpdateLock dbo 1 16 16 0
tbl_BuildOutput dbo 0 0 0 0
tbl_BuildServerProperties dbo 1 16 16 0
tbl_BuildSqlNotification dbo 124445 8432 6544 1888
tbl_Counter dbo 3 16 16 0
tbl_LastChangeId dbo 1 16 16 0
tbl_Replication dbo 1 16 16 0
tbl_Repository dbo 1 16 16 0
TempADObjectMemberships dbo 0 0 0 0
TempADObjects dbo 0 0 0 0
模板 dbo 7 41328 41280 48
4

3 回答 3

1

在您的情况下，大部分磁盘空间将由事务日志文件使用，而不是数据文件。

上面的查询仅显示数据文件使用的磁盘空间。

如果有可用空间，您可以考虑缩小事务日志。

于 2013-10-30T00:52:45.073 回答
1

在查看了TFS数据库事务日志的不合理增长后，我找不到增长的确切原因，也无法控制日志的自动收缩。

没有完整数据库备份的类似解决方案

我在非生产服务器上尝试了几天这个脚本，并且只有在我切换到生产服务器之后。

破坏 SQL Server 2012 和 TFS 2015

以下脚本会自动收缩事务日志。

使用SQL 作业完全备份后运行此脚本

脚本部分：

1）断开与特定数据库的所有连接

2) 将备份模式切换为简单模式

3) 将数据库日志大小设置为无限制

4) 将日志文件缩小到 200mb（或您希望的任何大小）

5）将最大尺寸设置为 50000（或您希望的任何尺寸）

6）将备份模型设置为完整

在 140GB 数据库上运行脚本大约需要 3 -5 秒 

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
于 2017-07-10T08:00:42.713 回答
0

我在遇到类似问题时发现的另一个建议是通过将表的恢复模式更改为“简单”来防止 LDF 文件重新增长。

首先，缩小 LDF 文件。我是使用 SQL 管理工作室完成的。

缩小数据库并确保 TFS 仍然有效后，请按照此处的说明进行操作：stop-sql-server-transaction-log-ldf-files-from-growth-indefinitely。

这将导致 SQL 服务器减少保存到事务日志的恢复数据量，这样您就不需要每 X 个月重复一次收缩操作。

于 2017-01-22T06:49:49.297 回答