由于wait_type RESOURCE_SEMAPHORE，CHECKDB永远不会完成，挂起

Question

我们有一个计划的数据库维护任务据报道需要更长时间才能完成，直到最后它完全停止完成。该任务针对特定数据库运行CHECKDB。

当我运行select * from sys.dm_exec_requests where (status = 'suspended')时，我看到了暂停的DBCC TABLE CHECK命令。取其session_id并将其与select * from sys.dm_exec_query_memory_grants的结果进行比较，我发现内存授予的requested_memory_kb为1515704kb（1.515GB）。 required_memory_kb仅为512kb。 resource_semaphore_id为0。

如果我运行select * from sys.dm_exec_query_resource_semaphores，我发现resource_sempahore_id 0的target_memory_kb为1174200kb，max_target_memory_kb为6063000kb，total_memory_kb为1174200kb， available_memory_kb的1174200kb。

看起来我的CHECKDB失败了，因为它的等待任务正在请求1.5GB的内存授权，但是资源信号量永远不能授予该内存，因为它的整个可用内存池只有1.17GB。尽管显示其max_target_memory_kb为6063000kb（6GB），但它永远不会超出其当前目标，即使由于内存不足而等待任务也是如此。

我正在努力确定：

1. 当required_memory_kb仅为512kb时，导致我的CHECKDB任务请求1.5GB内存授权的原因是什么。为什么要求的金额比所需金额高2950倍。
2. 为什么请求比SQL服务器更多内存的任务在其资源信号量中总共可用？ （1.5GB请求vs 1.15GB可用）
3. 如果不向我的SQL服务器添加更多内存，我有什么办法可以解决这个问题吗？

Answer 1

＆＃34;所需内存＆＃34;有点误导。 This article在解释所需内存和请求内存方面做得很好。简而言之，所需的内存就是在内存中执行必要的散列连接和排序所需的内存。请求的内存的剩余部分用于实际行。

您可能会执行DBCC CHECKDB WITH PHYSICAL_ONLY，它会检查页面的一致性等，但不会验证行级数据。否则，那里肯定存在内存瓶颈。