网络交换机的变化是否只是巧合，我们真的不知道，但在 7 月 19 日，网络交换机发生了变化，然后不久之后，我们每天运行的一项工作开始失败。我们没有更多关于开关变化的信息，除了它们发生在 19 日。该作业在 20 日运行正常，然后在 21 日失败，之后大约 4 或 5 次运行失败，直到其中一位用户抱怨他们没有报告中的数据。
作业日志文件上的错误是“由于文件组中的磁盘空间不足，无法为数据库 TEMPDB 分配新页面默认通过删除文件组中的对象、向文件组添加其他文件或为现有文件设置自动增长来创建必要的空间文件组中的文件“
我或我的同事都没有文件组或管理 tempdb 的经验或技能，因此我们的问题是看看我们可以做些什么来确定为什么会发生这种情况并解决它。我确实看过并且自动增长已打开，我不确定在文件组中删除对象的过程等。
我们已经从作业中识别出查询，但我们不相信这是问题所在，这是我们怀疑的其他问题的症状，因为此查询已经运行了很长一段时间。这项工作一夜之间从 6 秒缩短到 1 小时 38 分钟。由于工作性质，我无法按原样透露查询或任何数据。
当然，它处理大量的审计数据，但如前所述，我们以前没有遇到过这个问题。
我们让我们的网络人员增加了磁盘空间和内存；内存从 4GB 增加到 12GB，磁盘空间增加了 40GB。在此增加之前，它基本上处于最大磁盘空间。我们还将 tempdb 移至 100gb 驱动器。不过，这一切都只是暂时的，我认为这些很快就会填满。
然后我们重新运行了作业的查询部分，它用 12gb 填满了 tempdb，留下了 28gb 的备用磁盘空间，所以它很快就被填满了。按照这个估计，我们会在硬盘再次用尽之前再运行一两次，除非它溢出到给 tempdb 的额外空间中。
在其中一项工作失败时，我们还在其中一个数据库上收到了一条日志完整消息。我检查了该数据库的 sys.databases 表上的 log_reuse_wait_desc 列，它显示 log_backup。
正如我所说，我们在数据库这一领域没有太多经验，因此寻找一些指针/线索来确定可能导致问题的原因并从那里获取。
非常感谢
安德鲁