Auflösen der Wartetypen RESOURCE_SEMAPHORE und RESOURCE_SEMAPHORE_QUERY_COMPILE

Wir versuchen herauszufinden, warum SQL Server-Abfragen langsam ausgeführt werden und Daten aus einer der Datenbanken mit einer Größe von 300 GB abrufen, die auf einem Server mit der folgenden Konfiguration gehostet werden:

Windows Server 2003 R2, SP2, Enterprise Edition, 16 GB RAM, 12 CPUs, 32 Bit

SQL Server 2005, SP4, Enterprise Edition, 32 Bit.

Wir haben das Unternehmen bereits über das Upgrade auf 64-Bit informiert, das über einen Monat dauern würde.

Für die aktuelle Ausgabe versuchen wir jedoch, die Daten zu sammeln, um den Speicherdruck zu beheben oder um schließlich zu einer Schlussfolgerung zur Erhöhung des Arbeitsspeichers zu gelangen.

Aktion abgeschlossen: Neuindizierung und Aktualisierungsstatistik sind für diese Datenbank korrekt.

Wie unten gezeigt, haben wir seit 5 Tagen den Semaphor-Wartetyp festgestellt, der während der Ladestunden ausgeführt wurde:

Einige Informationen nach den folgenden Abfragen: Größe des Puffers = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

und Semaphorenspeicher = 644024 pro Abfrage unten

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

Im Folgenden finden Sie einige weitere Informationen von dm_exec_query_resource_semaphoresund sys.dm_exec_query_memory_grantsdmv's

Also von oben gesammelte Infos und pro SP_Blitz Daten scheint das Ressourcensemaphor das Problem zu sein.

Ist der für Ressourcensemaphor-IDs zugewiesene Speicher 'target_memory_kb' im Vergleich zu 16 GB verfügbarem RAM zu niedrig?

Hinweis * Pro Analyse und 8 Stunden Laufzeit liegt 'target_memory_kb' immer unter 1 GB, verglichen mit 16 GB, die verfügbar sind.

Was könnte das Problem hier sein und wie es zu lösen ist, schlagen Sie bitte vor

Vielen Dank

Meine Güte, ich habe hier eine schlechte Nachricht.

Auf einem 32-Bit-Betriebssystem verwendet SQL Server nur die ersten 4 GB Arbeitsspeicher für Aufgaben wie den Abfrage-Arbeitsbereich. (Und es kämpft auch gegen das Betriebssystem um diese 4 GB - alle anderen laufenden Apps konkurrieren ebenfalls um diesen Speicher.)

4 GB klingen vielleicht viel, aber es ist relativ einfach, eine Abfrage zu schreiben, für deren Ausführung mehrere GB Arbeitsspeicher erforderlich sind. Wenn genügend Abfragen genügend Arbeitsspeicher erfordern, wartet SQL Server mit RESOURCE_SEMAPHORE, da Abfragen nicht genügend Arbeitsspeicher abrufen können, um zu starten. RESOURCE_SEMAPHORE_QUERY_COMPILE bedeutet, dass sie nicht einmal genug Speicher zum Kompilieren eines Ausführungsplans erhalten können - und ja, das ist ziemlich schlecht.

Wie können Sie das Problem beheben?

• Wechseln Sie zu einem 64-Bit-Betriebssystem (das von Ihnen verwendete Betriebssystem wird sowieso nicht mehr unterstützt)
• Wechseln Sie zu einem 64-Bit-Build von SQL Server
• Reduzieren Sie den Speicherbedarf auf dem Server (führen Sie keine anderen Apps auf dieser Box aus, und dies ist besonders wichtig bei 32-Bit-Boxen, da nur 4 GB begrenzt sind).
• Verwenden Sie mit den AWE / PAE-Schaltern mehr Arbeitsspeicher. Dies funktioniert jedoch nicht, wenn RESOURCE_SEMAPHORE wartet, da SQL Server nur die ersten 4 GB für den Abfrage-Arbeitsbereich verwenden kann
• Optimieren Sie Abfragen und Indizes so, dass sie weniger Speicher benötigen

Ich zögere sogar, das letzte zu sagen, weil das 32-Bit-Problem so schlimm ist und es für die älteren Versionen von SQL Server sehr schwierig ist. Wenn Sie eine aktuelle Version verwenden, können Sie den Plan-Cache durchsuchen und Abfragen nach Speicherzuweisung sortieren, die größten Empfänger für Zuweisungen finden und diese optimieren. Keine Option für diese alte Antiquität.