当数据库仍然可以访问但流量很少时，我们有一个例行的 DBCC CHECKDB 在晚上运行。自上个月以来，我们有几次 DBCC CHECKDB 因此错误而崩溃：
由于错误状态 5，sqladmin 执行的带 no_infomsgs 的 DBCC CHECKDB (Database1) 异常终止。经过时间：0 小时 47 分 9 秒。
这之前有几个 SQL Alert Severity 17，这是资源不足，以及 SQL 服务器日志中 DBCC MEMORYSTATUS 的输出。因此我认为 DBCC CHECKDB 崩溃是由于内存不足。
再次运行 DBCC CHECKDB 不会返回错误。一个非 DBA 甚至在工作时间做了一次，虽然拖累了性能，花了将近 3 个小时才完成，但并没有导致内存问题。（他被告知不要再这样做了）。
服务器本身有 12GB 的 RAM，但没有为 SQ 服务器设置最小和最大限制。SQL Server 本身使用大约 10GB 内存，而所有其他进程使用 1GB。当时我不知道有什么其他事情对服务器征税。
编辑：
- 没有设置最小或最大内存限制，原始问题缺少关键字“否”
- temp DB 有足够的增长空间
- 任何卷上都没有磁盘空间警报，所以我认为磁盘空间不是问题
- 数据库大小约为 50GB
- 我不知道除 Windows 更新之外的任何系统更改
- 通常 CHECKDB 在晚上需要 60-90 分钟才能完成
声明“自上个月以来，我们有几次 DBCC CHECKDB 因此错误而崩溃......”让我认为上个月对您的系统进行了更改，这可能导致了这种情况。据你所知，上个月有什么实施吗？例如，在 SQL Server 上安装或升级了 SQL Server 的任何补丁、更新和应用程序等......
您是否尝试过以下帖子以查看问题是操作系统内存问题还是由 SQL 引起的错误？
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ff936d46-d210-4326-a112-0501a366ea41/dbcc-checkdb-failure-sql-2012-there-is-insufficient-system-memory- in-resource-pool-internal-to?forum=sqldatabaseengine
您可以尝试拆分 DBCC CheckDB 命令以帮助缓解任何资源限制。
将 DBCC CHECKDB 划分为多天
所以我决定设置一个较低的最大内存设置并监控服务器。运行 CHECKDB 50 分钟后，其中一个 svchost.exe 开始出现页面错误，可用内存迅速从 2GB 降至 0（但进程本身仅占用 300MB）。混乱持续了大约一分钟，然后系统稳定下来。这次CHECKDB没有中断，系统管理员被要求检查是哪个底层服务导致了这个问题——大约一个月前安装了一个新的监控工具。