小编Die*_*roz的帖子

我面临的情况有点难以解决。我需要帮助来了解正在发生的事情。

TL;DR：每次 SQL Server 中的事务日志已满时，它都需要关闭数据库以进入恢复模式并回滚有问题的事务吗？这总是由设计完成还是仅在发生不好的事情时才会发生？

场景：

我们大量使用的生产数据库之一，它运行多个 ETL 作业和长时间运行的表批处理，进入恢复模式并在一段时间内无法访问。这周发生了 3 次（这个服务器已经运行了大约 2 年，我们过去没有注意到这个问题）。

查看错误日志很清楚发生了什么：事务日志已满，数据库需要回滚事务，回滚失败，数据库关闭，并以恢复模式启动。

DBA 认为这是 SQL Server 的正常行为。也就是说，按照他的说法，每次事务日志满了，一个事务需要回滚，数据库就会因为日志空间不足而进入恢复模式。回滚后（根据他的说法只能在恢复模式下完成），数据库将再次可用。

我找不到此信息的参考。所以我强烈反对。如果有人让我相信我错了，我将不胜感激。

我的观点：

据我所知，DBMS 是用来管理/运行查询的。如果空间不足，查询将失败。就这么简单。我不是在谈论其他任何东西的性能，而只是在谈论可用性。

接受 DBMS在设计上需要关闭自身以回滚任何事务对我来说是没有意义的。根据我的理解，我是否正在运行大量查询或查询设计是否不当都无关紧要。错误的查询应该会失败，而生活仍在继续。不是吗？

我的猜测是其他原因导致它失败，我需要跟踪正在发生的事情。

我的理解是错误的还是这真的是 SQL Server 的设计方式？假设我没有错，我还能做些什么来追踪这个问题的来源？

一些附加信息

select @@version：Microsoft SQL Server 2012 (SP1) - 11.0.3156.0 (X64) 2015 年 5 月 4 日 18:48:09 版权所有 (c) Windows NT 6.2（内部版本 9200：）微软公司标准版（64 位）
此数据库处于简单恢复模式。
同一个实例中还有其他数据库。它们没有出现相同的问题，但它们也没有被大量使用。
只有事务日志已满，磁盘未满。磁盘有足够的空间，但数据库的日志大小有限。
我们监控这台服务器，CPU 负载正常，内存使用正常，磁盘使用 RAID-5，控制器没有崩溃或读取失败。资源使用有一些高峰，但并不少见。
我知道可以改进查询以有效地使用日志。我也知道我可以增加事务日志空间。但这真的不是我的重点。
最近聘请了一位 DBA 来管理这个数据库。所以最近更改了几个配置，用于调整目的。他让我知道所有的变化（比如禁用自动收缩、增加自动增长大小等）。我没有发现任何可能损害数据库的内容。

日志转储（按发生顺序，删除重复项）