Azure DevOps Server 数据库日志已满，TF30042: The database is full

关注

原创最新推荐文章于 2026-11-12 00:10:36 发布 558 阅读 AI 写同款· GEO 优化 ›

SpringBoot+Vue+MySQL 高校学科竞赛平台完整可运行版（源码+文档）本项目基于SpringBoot+Vue+MySQL构建高校学科竞赛管理平台，覆盖学生、教师、领队教师、管理员四大角色，实现竞赛发布、报名、刷题、评分、公示等全流程闭环管理。系统架构清晰，技术主流，配套完整源码、数据库脚本、万字论文、开题报告、答辩PPT及部署文档，支持一键运行，适用于毕业设计、课程设计及院系二次开发，真正实现“开箱即用”。阅读详情

Contents

1. 问题描述
2. 处理方式
- 2.1 系统备份
- 2.2 收缩日志
- 2.3 恢复模式
- 2.4 日志增长无法控制

1. 问题描述

Azure DevOps Server 作为微软的软件开发管理平台产品，理所当然地使用了微软的数据库软件SQL Server。

在一个大型的开发团队中，Azure DevOps Server 系统中存储了大量的代码、工作项和持续集成数据，用户频繁提交和更新数据，每天会产生大量的数据库日志，如果对数据库日志处理不当，就会产生如文章标题所示的问题“数据库日志已满，TF30042: The database is full”(如下图)，此时，用户可能无法使用任何客户端登录系统，即使偶尔登录成功，也不能提交任何更改。

图：由于数据库日志已满，DevOps Server 系统异常

2. 处理方式

在SQL Server中，日志文件的最大大小可以是2 TB(SQL Server 2016及以后版本)。然而，实际上，日志文件的大小受到操作系统文件大小限制的影响。例如，在32位操作系统上，最大文件大小通常限制为2 GB。在64位操作系统上，最大文件大小可以达到2 TB。如果日志文件超过了操作系统允许的最大文件大小，SQL Server将无法使用该日志文件，并可能报错。

如果数据库的日志文件已经达到了2TB，那么管理员必须采取相关措施才能保证系统运行正常，参考笔者最近处理的几个数据库日志的问题，总结可以采取下面的几种处理方式：

2.1 系统备份

对Azure DevOps Server系统启动定时备份(如下图)，不仅可以保障数据的安全性，同时还能起到自动截断日志的功能。

一般在配置自动备份时，需要将完整备份和差异备份结合起来使用，这样不仅可以节省磁盘，还能提高备份的速度；例如我们可以将周六设定为完整备份的时间，将其他日期设置为差异备份的时间。当系统完成完整备份后，数据库会将日志截断，此后产生的日志可以利用之前的日志文件空间，从而确保日志文件不会无限制增长。

图：备份计划

如果在一个用户量巨大且更新非常频繁的环境中，还需要考虑事务日志备份；一周一次全量备份，同时截断日志，但是在一周过程中如果数据变化量太大，可能会导致一周的日志增长量超过了2TB，就可能出现前面说到的TF30042错误。在这种场景中，我们可以启用事务日志(如下图)，例如我们配置为“每60分钟”执行一次事务日志备份；当事务日志备份完成后，数据库也会自动截断日志，此后产生的日志可以利用之前的日志文件空间。

图：配置事务日志备份

2.2 收缩日志

如果由于特殊原因导致日志太大，或已经增长到了2TB，我们可以在数据库软件中，通过收缩数据库文件的方式来缩小日志文件。

如下图，我们使用SQL Server的数据库管理工具SQL Server Management Studio链接到数据库服务器，并启动收缩文件功能。

2.3 恢复模式

如果很不幸，你的数据库日志文件已经增长到了2TB，那么使用上面收缩数据库文件的方式已经行不通，我们必须将数据库的恢复模式设置为“简单”，再收缩数据库日志文件。

在SQL Server中，如果我们将数据库的恢复模式设置为“简单”，此时系统不会将日志存储到日志文件中，因此日志文件不会再增长；但是这种设置带来的风险也显而易见，万一出现故障，你不能将数据库恢复到特定的时间点。

设置数据库简单恢复模式的操作视图如下：

2.4 日志增长无法控制

最近和一个客户处理了一个“日志增长无法控制”的问题，这个问题比较特殊，但是如果在一个大型的Azure DevOps Server部署场景中，这个现象可能比较普遍。

事情的起源是这样的，这个部署环境中有大约3千用户，数据库已经达到15TB，每日的数据变化非常频繁；用户发现近期的数据完整备份正常，但是日志文件却没有自动截断，不停的增长，已经接近2TB。管理员将数据库从AlwaysOn中移除出来，并且将数据库的恢复模式设置为简单，但是日志的增长还是无法控制；并且使用收缩日志的方式也不能减少日志文件。

通过分析数据库中长时间运行的脚本，发现有一个Alter Index的session一直在运行，且已经持续了好几天；我们使用数据库的kill命令终止了这个进程后，发现日志马上停止了增长，并且也将日志文件收到到最小。

Azure DevOps Server使用Alter Index重建索引，由于数据量太大，重建索引的操作持续时间过长，从而引发日志文件不能收缩。这种问题的产生源于SQL Server的设计机制，在SQL Server中，如果存在一个长时间的更新操作，在此期间系统不允许截断日志。这种长时间的索引，主要是由于我们对团队项目集合启用了分析功能(如下图)，而团队项目集合中的数据量太大，就出现了上面描述的问题。