Behandeln von Problemen mit unzureichendem oder wenig Arbeitsspeicher in SQL Server

Artikel
12/23/2024

Problembeschreibung

SQL Server verwendet eine komplexe Speicherarchitektur , die dem komplexen und umfangreichen Featuresatz entspricht. Aufgrund der Unterschiedlichkeit der Speicheranforderungen könnte es viele Quellen für Arbeitsspeicherverbrauch und Speicherdruck geben, was letztendlich zu Speicherbedingungen führt.

Es gibt häufige Fehler, die auf geringen Arbeitsspeicher in SQL Server hinweisen. Beispiele für Fehler sind:

701: Fehler beim Zuweisen ausreichender Arbeitsspeicher zum Ausführen einer Abfrage.
802: Fehler beim Abrufen des Arbeitsspeichers zum Zuordnen von Seiten im Pufferpool (Daten- oder Indexseiten).
1204: Fehler beim Zuweisen des Speichers für Sperren.
6322: Fehler beim Zuordnen des Arbeitsspeichers für den XML-Parser.
6513:Fehler beim Initialisieren von CLR aufgrund des Arbeitsspeicherdrucks.
6533: AppDomain wurde aufgrund des Arbeitsspeichers entladen.
8318: Fehler beim Laden von SQL-Leistungsindikatoren aufgrund unzureichendem Arbeitsspeicher.
8356 oder 8359: DIE ETW- oder SQL-Ablaufverfolgung kann aufgrund von geringem Arbeitsspeicher nicht ausgeführt werden.
8556: Fehler beim Laden von MSDTC aufgrund unzureichender Arbeitsspeicher.
8645: Fehler beim Ausführen einer Abfrage, da keine Speicher für Speichererteilungen (Sortierung und Hashing) vorhanden ist. Weitere Informationen finden Sie unter Problembehandlung für SQL Server-Fehler 8645.
8902: Fehler beim Zuweisen von Arbeitsspeicher während der DBCC-Ausführung.
9695 oder 9696: Fehler beim Zuweisen des Speichers für Service Broker-Vorgänge.
17131 oder 17132: Serverstartfehler aufgrund unzureichender Arbeitsspeicher.
17890: Fehler beim Zuweisen von Arbeitsspeicher aufgrund des ausgelagerten SQL-Speichers durch das Betriebssystem.
18053: Der Fehler wird im Tersemodus gedruckt, da während der Formatierung Fehler aufgetreten sind. Ablaufverfolgung, ETW, Benachrichtigungen usw. werden ausgelassen.
22986 oder 22987: Ändern von Datenerfassungsfehlern aufgrund unzureichendem Arbeitsspeicher.
25601: Das Xevent-Modul ist nicht genügend Arbeitsspeicher.
26053: SQL-Netzwerkschnittstellen können aufgrund unzureichendem Arbeitsspeicher nicht initialisiert werden.
30085, 30086, 30094: SQL-Volltextvorgänge schlagen aufgrund unzureichender Arbeitsspeicher fehl.

Ursache

Viele Faktoren können zu unzureichendem Arbeitsspeicher führen. Zu diesen Faktoren gehören Betriebssystemeinstellungen, physische Speicherverfügbarkeit, Komponenten, die Arbeitsspeicher innerhalb von SQL Server verwenden, und Speicherbeschränkungen für die aktuelle Workload. In den meisten Fällen ist die Abfrage, die mit einem Fehler außerhalb des Arbeitsspeichers fehlschlägt, nicht die Ursache dieses Fehlers. Insgesamt können die Ursachen in drei Kategorien unterteilt werden:

Ursache 1: Externer oder Betriebssystemspeicherdruck

Die externe Auslastung bezieht sich auf eine hohe Arbeitsspeicherauslastung, die durch eine Komponente außerhalb des Prozesses verursacht wird, was dazu führt, dass unzureichend Arbeitsspeicher für SQL Server verfügbar ist. Sie müssen herausfinden, ob andere Anwendungen auf dem System Arbeitsspeicher verbrauchen und zu geringer Speicherverfügbarkeit beitragen. SQL Server ist eine der wenigen Anwendungen, die darauf ausgelegt sind, auf den Arbeitsspeicherdruck des Betriebssystems zu reagieren, indem sie die Speichernutzung kürzen. Dies bedeutet, dass eine Anwendung oder ein Treiber Speicher anfordert, das Betriebssystem ein Signal an alle Anwendungen sendet, um Arbeitsspeicher freizugeben, und SQL Server reagiert, indem die eigene Speicherauslastung reduziert wird. Einige andere Anwendungen reagieren, da sie nicht darauf ausgelegt sind, auf diese Benachrichtigung zu lauschen. Wenn SQL Server daher mit dem Kürzen der Speicherauslastung beginnt, wird der Speicherpool reduziert, und je nachdem, welche Komponenten Arbeitsspeicher benötigen, wird möglicherweise nicht abgerufen. Daher erhalten Sie 701 oder andere Speicherfehler. Weitere Informationen zum dynamischen Zuweisen und Freigeben von Arbeitsspeicher in SQL Server finden Sie unter SQL Server Memory Architecture. Ausführlichere Diagnosen und Lösungen für das Problem finden Sie unter externem Arbeitsspeicherdruck in diesem Artikel.

Es gibt drei allgemeine Kategorien von Problemen, die zu Betriebssystemspeicherdruck führen können:

Anwendungsbezogene Probleme: Eine oder viele Anwendungen erschöpfen gemeinsam den verfügbaren physischen Speicher. Das Betriebssystem antwortet auf neue Anwendungsanforderungen für Ressourcen, indem versucht wird, Speicherplatz freizugeben. Der gemeinsame Ansatz besteht darin, zu finden, welche Anwendungen den Arbeitsspeicher ausschöpfen und die erforderlichen Schritte unternehmen, um den Speicher zwischen ihnen zu ausgleichen, ohne zu EINER RAM-Ausschöpfung zu führen.
Gerätetreiberprobleme: Gerätetreiber können die Auslagerung aller Prozesse verursachen, wenn der Treiber fälschlicherweise eine Speicherzuweisungsfunktion aufruft.
Probleme mit dem Betriebssystemprodukt.

Eine ausführliche Erläuterung dieser und Problembehandlungsschritte finden Sie unter MSSQLSERVER_17890.

Ursache 2: Interner Arbeitsspeicherdruck, der nicht von SQL Server stammt

Die interne Arbeitsspeicherauslastung bezieht sich auf eine geringe Arbeitsspeicherverfügbarkeit, die durch Faktoren innerhalb des SQL Server-Prozesses verursacht wird. Einige Komponenten, die im SQL Server-Prozess ausgeführt werden können, sind "extern" für das SQL Server-Modul. Beispiele sind OLE DB-Anbieter (DLLs) wie verknüpfte Server, SQLCLR-Prozeduren oder Funktionen, erweiterte Prozeduren (XPs) und OLE-Automatisierung (sp_OA*). Andere umfassen Virenschutzprogramme oder andere Sicherheitsprogramme, die DLLs zu Überwachungszwecken in einen Prozess einfügen. Ein Problem oder ein schlechtes Design in einer dieser Komponenten kann zu einem hohen Arbeitsspeicherverbrauch führen. Angenommen, ein verknüpfter Server zwischenspeichert 20 Millionen Datenzeilen aus einer externen Quelle im SQL Server-Speicher. Was SQL Server betrifft, meldet kein Arbeitsspeicherclerk eine hohe Arbeitsspeicherauslastung, aber der im SQL Server-Prozess verbrauchte Arbeitsspeicher ist hoch. Dieses Speicherwachstum von einer verknüpften Server-DLL würde z. B. dazu führen, dass SQL Server seine Speicherauslastung (siehe oben) abschneidet und niedrige Speicherbedingungen für Komponenten innerhalb von SQL Server erzeugt, was zu Speicherfehlern führt. Ausführlichere Diagnosen und Lösungen zu diesem Problem finden Sie unter interner Speicherdruck, der nicht von SQL Server stammt.

Notiz

Einige Microsoft-DLLs, die im SQL Server-Prozessbereich (z. B. MSOLEDBSQL, SQL Native Client ) verwendet werden, sind in der Lage, eine Schnittstelle mit der SQL Server-Speicherinfrastruktur für die Berichterstellung und -zuordnung zu erstellen. Sie können ausführen select * from sys.dm_os_memory_clerks where type='MEMORYCLERK_HOST' , um eine Liste dieser Dateien abzurufen und den Speicherverbrauch für einige ihrer Zuordnungen nachzuverfolgen.

Ursache 3: Interner Speicherdruck aus SQL Server-Komponenten(en)

Interner Speicherdruck, der aus Komponenten innerhalb des SQL Server-Moduls kommt, kann auch zu Speicherfehlern führen. Es gibt Hunderte von Komponenten, die über Speicherbearbeiter nachverfolgt werden, die Speicher in SQL Server zuweisen. Sie müssen ermitteln, welche Speichermitarbeiter für die größten Speicherzuweisungen verantwortlich sind, um dieses Problem zu beheben. Wenn Sie beispielsweise feststellen, dass der OBJECTSTORE_LOCK_MANAGER Speicherkaufmann eine große Speicherzuweisung anzeigt, müssen Sie verstehen, warum der Sperr-Manager so viel Arbeitsspeicher verbraucht. Möglicherweise gibt es Abfragen, die viele Sperren erwerben. Sie können diese Abfragen optimieren, indem Sie Indizes verwenden, transaktionen verkürzen, die sperren, lange zeitlang sperren oder überprüfen, ob die Sperreskalation deaktiviert ist. Jeder Arbeitsspeicherclerk oder jede Komponente hat eine einzigartige Methode, auf Arbeitsspeicher zuzugreifen und diesen zu verwenden. Weitere Informationen und Beschreibungen finden Sie im Artikel zu den verschiedenen Typen von Arbeitsspeicherclerks. Ausführlichere Diagnosen und Lösungen für das Problem finden Sie unter "Interne Speicherauslastung durch das SQL Server-Modul".

Visuelle Darstellung der Speicherdrucktypen

Die folgende Abbildung veranschaulicht die Drucktypen, die zu nicht genügend Arbeitsspeicherbedingungen in SQL Server führen können:

Screenshot der Speicherdrucktypen.

Diagnosetools zum Sammeln von Problembehandlungsdaten

Sie können die folgenden Diagnosetools verwenden, um Problembehandlungsdaten zu sammeln:

Systemmonitor

Konfigurieren und erfassen Sie die folgenden Leistungsindikatoren mit der Leistungsüberwachung:

Arbeitsspeicher:Verfügbare MBytes
Process:Working Set
Process:Private Bytes
SQL Server:Memory Manager: (alle Leistungsindikatoren)
SQL Server:Buffer Manager: (alle Leistungsindikatoren)

DMVs oder DBCC MEMORYSTATUS

Sie können sys.dm_os_memory_clerks oder DBCC MEMORYSTATUS verwenden, um die gesamte Speicherauslastung in SQL Server zu beobachten.

Standardbericht zur Speicherauslastung in SSMS

Anzeigen der Speicherauslastung in SQL Server Management Studio:

Starten Sie SQL Server Management Studio, und stellen Sie eine Verbindung mit einem Server her.
Klicken Sie in Objekt-Explorer mit der rechten Maustaste auf den NAMEN der SQL Server-Instanz.
Wählen Sie im Kontextmenü die Option "Berichte>Standardberichtsspeicherverbrauch">aus.

PSSDiag oder SQL LogFinder

Eine alternative, automatisierte Möglichkeit zum Erfassen dieser Datenpunkte ist die Verwendung von Tools wie PSSDiag oder SQL LogFinder.

Wenn Sie PSSDiag verwenden, konfigurieren Sie sie, um den Perfmon-Sammler und den Benutzerdefinierten Diagnose\SQL-Speicherfehlersammler zu erfassen.
Wenn Sie SQL LogFinder verwenden, konfigurieren Sie es, um das Speicherszenario zu erfassen.

In den folgenden Abschnitten werden detailliertere Schritte für jedes Szenario beschrieben (externer oder interner Speicherdruck).

Problembehandlungsmethoden

Wenn gelegentlich ein Speicherfehler außerhalb des Arbeitsspeichers oder für einen kurzen Zeitraum angezeigt wird, liegt möglicherweise ein kurzlebiges Speicherproblem vor, das sich selbst behebt. In diesen Fällen müssen Sie möglicherweise keine Maßnahmen ergreifen. Wenn der Fehler jedoch mehrmals auf mehreren Verbindungen auftritt und für Zeiträume von Sekunden oder länger beibehalten wird, befolgen Sie die Diagnose und Lösungen in den folgenden Abschnitten, um Speicherfehler weiter zu beheben.

Externer Arbeitsspeicherdruck

Verwenden Sie die folgenden Methoden, um niedrige Arbeitsspeicherbedingungen für das System außerhalb des SQL Server-Prozesses zu diagnostizieren:

Sammeln Sie Leistungsmonitor Leistungsindikatoren. Untersuchen Sie anhand der folgenden Leistungsindikatoren, ob andere Anwendungen oder Dienste als SQL Server Arbeitsspeicher auf diesem Server verbrauchen:

Arbeitsspeicher:Verfügbare MBytes
Process:Working Set
Process:Private Bytes

Hier ist ein Beispiel für die Perfmon-Protokollauflistung mithilfe von PowerShell:

clear
$serverName = $env:COMPUTERNAME
$Counters = @(
   ("\\$serverName" +"\Memory\Available MBytes"),
   ("\\$serverName" +"\Process(*)\Working Set"),
   ("\\$serverName" +"\Process(*)\Private Bytes")
)

Get-Counter -Counter $Counters -SampleInterval 2 -MaxSamples 1 | ForEach-Object  {
$_.CounterSamples | ForEach-Object   {
   [pscustomobject]@{
      TimeStamp = $_.TimeStamp
      Path = $_.Path
      Value = ([Math]::Round($_.CookedValue, 3)) }
}
}

Überprüfen Sie das Systemereignisprotokoll, und suchen Sie nach Fehlern in Bezug auf den Arbeitsspeicher (z. B. zu wenig virtueller Arbeitsspeicher).
Überprüfen Sie das Anwendungsereignisprotokoll auf anwendungsbezogene Speicherprobleme.

Hier ist ein Beispiel für ein PowerShell-Skript zum Abfragen der System- und Anwendungsereignisprotokolle für das Schlüsselwort "Memory". Sie können andere Zeichenfolgen wie "Ressource" für Ihre Suche verwenden:
```
Get-EventLog System -ComputerName "$env:COMPUTERNAME" -Message "*memory*"
Get-EventLog Application -ComputerName "$env:COMPUTERNAME" -Message "*memory*"
```
Beheben Sie Code- oder Konfigurationsprobleme für weniger kritische Anwendungen oder Dienste, um deren Arbeitsspeicherauslastung zu reduzieren.
Wenn Anwendungen neben SQL Server Ressourcen verbrauchen, versuchen Sie, diese Anwendungen zu beenden oder neu zu planen, oder erwägen Sie, sie auf einem separaten Server auszuführen. Durch diese Schritte wird der Mangel an externem Arbeitsspeicher beseitigt.

Interne Arbeitsspeicherauslastung, die nicht durch SQL Server verursacht wird

Verwenden Sie die folgenden Methoden, um internen Speicherdruck zu diagnostizieren, der durch Module (DLLs) innerhalb von SQL Server verursacht wird:

Wenn SQL Server keine gesperrten Seiten im Arbeitsspeicher (AWE-API) verwendet, wird der großteil des Speichers im Prozess:Private Bytes-Leistungsindikator (SQLServrInstanz) in Leistungsmonitor widergespiegelt. Die allgemeine Speicherauslastung, die aus dem SQL Server-Modul stammt, wird im SQL Server:Memory Manager: Total Server Memory (KB)- Zähler widerspiegelt. Wenn Sie einen signifikanten Unterschied zwischen dem Wert "Process:Private Bytes " und "SQL Server:Memory Manager: Gesamter Serverspeicher (KB)" feststellen, kommt dieser Unterschied wahrscheinlich von einer DLL (verknüpfter Server, XP, SQLCLR usw.). Wenn private Bytes z. B. 300 GB groß sind und der Gesamtspeicher des Servers 250 GB beträgt, stammen ca. 50 GB gesamter Arbeitsspeicher im Prozess von außerhalb des SQL Server-Moduls.
Wenn SQL Server gesperrte Seiten im Arbeitsspeicher (AWE-API) verwendet, ist es schwieriger, das Problem zu identifizieren, da die Leistungsmonitor keine AWE-Leistungsindikatoren bietet, die die Speicherauslastung für einzelne Prozesse nachverfolgen. Die allgemeine Speicherauslastung innerhalb des SQL Server-Moduls wird im SQL Server:Memory Manager: Total Server Memory (KB)- Zähler wiedergegeben. Typische Werte für Process:Private Bytes können zwischen 300 MB und 1 bis 2 GB insgesamt variieren. Wenn Sie eine signifikante Verwendung von Process:Private Bytes über diese typische Verwendung hinaus finden, kommt der Unterschied wahrscheinlich von einer DLL (verknüpfter Server, XP, SQLCLR usw.). Wenn der Indikator für private Bytes beispielsweise 4-5 GB beträgt und SQL Server gesperrte Seiten im Arbeitsspeicher (AWE) verwendet, kann ein großer Teil der privaten Bytes von außerhalb des SQL Server-Moduls stammen. Dies ist ein Näherungsverfahren.
Verwenden Sie das Hilfsprogramm „tasklist“, um alle DLLs zu identifizieren, die im SQL Server-Bereich geladen werden:
```
tasklist /M /FI "IMAGENAME eq sqlservr.exe"
```
Sie können auch die folgende Abfrage verwenden, um geladene Module (DLLs) zu untersuchen und festzustellen, ob etwas Unerwartetes vorhanden ist.
```
SELECT * FROM sys.dm_os_loaded_modules
```
Wenn Sie vermuten, dass ein Linked Server-Modul einen erheblichen Arbeitsspeicherverbrauch verursacht, können Sie es so konfigurieren, dass der Prozess nicht mehr ausgeführt wird, indem Sie die Option "Inprocess zulassen" deaktivieren. Weitere Informationen finden Sie unter Erstellen von Verbindungsservern. Nicht alle verknüpften Server-OLE DB-Anbieter laufen möglicherweise nicht mehr verarbeitet. Für weitere Informationen wenden Sie sich an den Produkthersteller.
In dem seltenen Fall, in dem OLE-Automatisierungsobjekte (sp_OA*) verwendet werden, können Sie das Objekt so konfigurieren, dass es in einem Prozess außerhalb von SQL Server ausgeführt wird, indem Sie einen Kontextwert von 4 (nur .exe) OLE-Server angeben). Weitere Informationen finden Sie unter sp_OACreate.

Interne Speicherauslastung durch das SQL Server-Modul

Verwenden Sie die folgenden Methoden, um den internen Speicherdruck zu diagnostizieren, der von Komponenten innerhalb des SQL Server-Moduls stammt:

Beginnen Sie mit dem Sammeln von Leistungsmonitor Zählern für SQL Server: SQL Server:Buffer Manager und SQL Server: Memory Manager.
Fragen Sie die dynamische Verwaltungssicht der SQL Server-Arbeitsspeicherclerks mehrmals ab, um herauszufinden, wo der höchste Arbeitsspeicherverbrauch innerhalb der Engine vorliegt:
```
SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC
```
Alternativ können Sie die detailliertere DBCC MEMORYSTATUS Ausgabe und die Art und Weise beobachten, wie sie sich ändert, wenn diese Fehlermeldungen angezeigt werden.
```
DBCC MEMORYSTATUS
```
Wenn Sie herausgefunden haben, welcher der Arbeitsspeicherclerks am meisten Arbeitsspeicher verbraucht, konzentrieren Sie sich auf die Besonderheiten des Arbeitsspeicherverbrauchs durch diese Komponente. Beispiele:
- Wenn der Speicherbearbeiter MEMORYCLERK_SQLQERESERVATIONS Arbeitsspeicher verbraucht, identifizieren Sie Abfragen, die große Speichererteilungen verwenden, und optimieren Sie sie über Indizes, schreiben Sie sie neu (z. B. entfernenORDER by), oder wenden Sie Abfragehinweise für die Speichererteilung an (siehe min_grant_percent und max_grant_percent Hinweise). Sie können auch einen Ressourcen-Gouverneurspool erstellen, um die Verwendung des Arbeitsspeichers für die Speichererteilung zu steuern. Ausführliche Informationen zu Speichererteilungen finden Sie unter Problembehandlung bei langsamen Oder geringen Arbeitsspeicherproblemen, die durch Speichererteilungen in SQL Server verursacht werden.
- Wenn eine große Anzahl von Ad-hoc-Abfrageplänen zwischengespeichert wird, würde der CACHESTORE_SQLCP Speicherbearbeiter große Speichermengen verwenden. Identifizieren Sie nicht parametrisierte Abfragen, deren Abfragepläne nicht wiederverwendet und parametrisiert werden können, indem Sie sie in gespeicherte Prozeduren konvertieren, verwenden sp_executesqloder die Parameterisierung verwenden FORCED . Wenn Sie das Ablaufverfolgungskennzeichnung 174 aktiviert haben, können Sie es deaktivieren, um festzustellen, ob das Problem dadurch behoben wird.
- Wenn der Cachespeicher CACHESTORE_OBJCP des Objektplans zu viel Arbeitsspeicher verbraucht, identifizieren Sie, welche gespeicherten Prozeduren, Funktionen oder Trigger große Speichermengen verwenden und möglicherweise die Anwendung neu entwerfen. In der Regel kann dies aufgrund großer Mengen von Datenbanken oder Schemas mit hunderten von Prozeduren in jedem auftreten.
- Wenn der OBJECTSTORE_LOCK_MANAGER Speicherkaufmann große Speicherzuweisungen anzeigt, identifizieren Sie Abfragen, die viele Sperren anwenden und mithilfe von Indizes optimieren. Verkürzen Sie Transaktionen, die dazu führen, dass Sperren nicht für lange Zeiträume in bestimmten Isolationsstufen freigegeben werden, oder überprüfen Sie, ob die Sperreskalation deaktiviert ist.
- Wenn Sie sehr groß TokenAndPermUserStore (select type, name, pages_kb from sys.dm_os_memory_clerks where name = 'TokenAndPermUserStore') beobachten, können Sie das Ablaufverfolgungskennzeichnung 4618 verwenden, um die Größe des Caches zu begrenzen.
- Wenn Sie Speicherprobleme mit in-Memory OLTP beobachten, die vom Speicherkaufmann stammen, können Sie unter "Überwachen und Behandeln von Problemen bei der MEMORYCLERK_XTP Speicherauslastung für in-Memory OLTP" und speicheroptimierte tempdb-Metadaten (HkTempDB) aus Speicherfehlern verweisen.

Schnelle Lösung, die möglicherweise Arbeitsspeicher verfügbar macht

Die folgenden Aktionen geben möglicherweise Arbeitsspeicher frei und stellen sie SQL Server zur Verfügung:

Ändern von Speicherkonfigurationseinstellungen

Überprüfen Sie die folgenden Parameter für die SQL Server-Arbeitsspeicherkonfiguration, und erwägen Sie nach Möglichkeit eine Erhöhung von Max. Serverarbeitsspeicher:

Max. Serverarbeitsspeicher
Min. Serverarbeitsspeicher

Notiz

Wenn Sie ungewöhnliche Einstellungen bemerken, korrigieren Sie sie bei Bedarf, und berücksichtigen Sie erhöhte Speicheranforderungen. Die Standardeinstellungen sind unter Konfigurationsoptionen für den Serverarbeitsspeicher aufgeführt.

Wenn Sie nicht den maximalen Serverspeicher konfiguriert haben, insbesondere bei gesperrten Seiten im Arbeitsspeicher, sollten Sie ihn auf einen bestimmten Wert festlegen, um Arbeitsspeicher für das Betriebssystem zuzulassen. Siehe die Option "Gesperrte Seiten" in der Speicherserverkonfigurationsoption .

Ändern oder Verschieben der Arbeitsauslastung vom System

Untersuchen Sie die Abfragearbeitsauslastung: Anzahl der gleichzeitigen Sitzungen, derzeit ausgeführte Abfragen, und überprüfen Sie, ob weniger kritische Anwendungen vorhanden sind, die vorübergehend beendet oder auf einen anderen SQL Server verschoben werden können.

Bei schreibgeschützten Workloads sollten Sie sie in einer AlwaysOn-Umgebung in ein schreibgeschütztes sekundäres Replikat verschieben. Weitere Informationen finden Sie unter "Offload read-only workload to secondary replica of an Always On availability group " und Configure read-only access to a secondary replica of an Always On availability group.

Sicherstellen der richtigen Speicherkonfiguration für virtuelle Computer

Wenn Sie die SQL Server auf einem virtuellen Computer (VM) ausführen, stellen Sie sicher, dass der Arbeitsspeicher für den virtuellen Computer nicht überlastet ist. Ideen zum Konfigurieren des Arbeitsspeichers für VMs finden Sie unter Virtualisierung – Überlastung des Arbeitsspeichers und wie Sie ihn innerhalb der VM erkennen und Probleme mit der Leistung von ESX/ESXi-Computern beheben können (Speicherüberlegung).

Freigeben des Arbeitsspeichers in SQL Server

Sie können einen oder mehrere der folgenden DBCC-Befehle ausführen, um mehrere SQL Server-Speichercaches freizugeben:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Starten Sie den SQL Server-Dienst neu.

Wenn Sie in einigen Fällen mit der kritischen Ausschöpfung des Arbeitsspeichers umgehen müssen und SQL Server Abfragen nicht verarbeiten kann, können Sie den Dienst neu starten.

Erwägen Sie die Verwendung des Ressourcengouverneurs für bestimmte Szenarien

Wenn Sie die Ressourcenkontrolle verwenden, empfehlen wir, die Einstellungen der Ressourcenpool- und Workloadgruppe zu überprüfen, um festzustellen, ob sie den Arbeitsspeicher nicht zu drastisch einschränken.

Hinzufügen weiterer RAM auf dem physischen oder virtuellen Server

Wenn das Problem weiterhin besteht, müssen Sie weitere untersuchen und möglicherweise Serverressourcen (RAM) erhöhen.

Freigeben über