CHECKDB wird nie abgeschlossen, hängt aufgrund von wait_type RESOURCE_SEMAPHORE

Question

Wir haben eine geplante Datenbankwartungsaufgabe, von der berichtet wurde, dass sie länger und länger dauert, bis sie schließlich vollständig beendet wurde. Die Task führt eine CHECKDB für eine bestimmte Datenbank aus.

Wenn ich select * from sys.dm_exec_requests where (status = 'suspended') ausführen sehe ich den suspendierten Befehl. Nimm seine session_id und vergleiche es mit den Ergebnissen von select * from sys.dm_exec_query_memory_grants Ich sehe, dass die Speichergewährung eine requested_memory_kb von 1515704kb (1.515GB) hat. required_memory_kb ist nur 512kb. resource_semaphore_id ist 0.

Wenn ich select * from sys.dm_exec_query_resource_semaphores betreibe ich sehe, dass die von 1174200kb hat, max_target_memory_kb von 6063000kb, eine total_memory_kb von 1174200kb und ein available_memory_kb von 1174200kb.

Es sieht so aus, als ob meine CHECKDB fehlschlägt, da ihre wartende Task 1,5 GB Speicher-Grant anfordert, aber der Resource-Semaphor wird niemals diesen Speicher freigeben können, da sein gesamter verfügbarer Speicherpool nur 1,17 GB beträgt. Obwohl es seine max_target_memory_kb bei 6063000kb (6GB) zeigt, wird es nie über sein aktuelles Ziel hinaus wachsen, selbst wenn eine Aufgabe aufgrund unzureichenden Speichers wartet.

Ich versuche zu bestimmen:

1. Was meine CHECKDB Aufgabe verursacht 1,5 GB Speicher Finanzhilfe zu verlangen, wenn der required_memory_kb nur 512kb ist. Warum ist der angeforderte Betrag 2950-mal höher als die erforderliche Menge?
2. Warum ist eine Task, die mehr Speicher als der SQL-Server benötigt, in ihrem Ressourcensemaphor insgesamt verfügbar? (1.5GB angefordert gegen 1.15GB verfügbar)
3. Gibt es irgendetwas, das ich tun kann, um dieses zu lösen, ohne einfach mehr RAM meinem SQL-Server hinzuzufügen?

Answer 1

"Erforderliche Speicher" ist ein wenig irreführend. This article erklärt sehr gut die erforderliche und die angeforderte Speicherkapazität. Kurz gesagt, erforderlicher Speicher ist genau das, was erforderlich wäre, um die notwendigen Hash-Joins und -Sortierungen im Speicher durchzuführen. Der Rest des angeforderten Speichers ist für tatsächliche Zeilen.

Sie könnten möglicherweise DBCC CHECKDB WITH PHYSICAL_ONLY tun, die die Konsistenz von Seiten usw. überprüft, aber Daten auf Zeilenebene nicht überprüfen. Sonst gibt es definitiv einen Speicherengpass.