Behandeln von Problemen mit unzureichendem Arbeitsspeicher oder unzureichendem Arbeitsspeicher in SQL Server

Symptome

SQL Server verwendet eine komplexe Speicherarchitektur, die dem komplexen und umfangreichen Featuresatz entspricht. Aufgrund der unterschiedlichen Speicheranforderungen kann es viele Quellen für Arbeitsspeicherverbrauch und Arbeitsspeicherauslastung geben, was letztendlich zu Nicht genügend Arbeitsspeicher führt.

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

• 701: Fehler beim Zuweisen von genügend Arbeitsspeicher zum Ausführen einer Abfrage.
• 802: Fehler beim Abrufen von Arbeitsspeicher zum Zuordnen von Seiten im Pufferpool (Daten- oder Indexseiten).
• 1204: Fehler beim Zuweisen von Speicher für Sperren.
• 6322: Fehler beim Zuweisen von Arbeitsspeicher für DEN XML-Parser.
• 6513: Fehler beim Initialisieren der CLR aufgrund von Arbeitsspeicherauslastung.
• 6533: AppDomain wurde aufgrund von nicht genügend Arbeitsspeicher entladen.
• 8318: Fehler beim Laden von SQL-Leistungsindikatoren aufgrund von unzureichendem Arbeitsspeicher.
• 8356 oder 8359: ETW oder SQL-Ablaufverfolgung kann aufgrund von wenig Arbeitsspeicher nicht ausgeführt werden.
• 8556: Fehler beim Laden von MSDTC aufgrund von unzureichendem Arbeitsspeicher.
• 8645: Fehler beim Ausführen einer Abfrage, weil kein Arbeitsspeicher für Speicherzuweisungen (Sortieren 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 von Arbeitsspeicher für Service Broker-Vorgänge.
• 17131 oder 17132: Serverstartfehler aufgrund von unzureichendem Arbeitsspeicher.
• 17890: Fehler beim Zuweisen von Arbeitsspeicher, weil SQL-Arbeitsspeicher vom Betriebssystem ausgelagert wird.
• 22986 oder 22987: Change Data Capture-Fehler aufgrund von unzureichendem Arbeitsspeicher.
• 25601: Die Xevent-Engine hat nicht genügend Arbeitsspeicher.
• 26053: SQL-Netzwerkschnittstellen können aufgrund von unzureichendem Arbeitsspeicher nicht initialisiert werden.
• 30085, 30086, 30094: SQL-Volltextvorgänge schlagen aufgrund von unzureichendem Arbeitsspeicher fehl.

Ursache

Viele Faktoren können zu unzureichendem Arbeitsspeicher führen. Zu diesen Faktoren gehören Betriebssystemeinstellungen, verfügbarkeit des physischen Speichers, Komponenten, die Arbeitsspeicher in SQL Server verwenden, und Arbeitsspeichergrenzwerte für die aktuelle Workload. In den meisten Fällen ist die Abfrage, die mit einem Fehler vom Typ "Nicht genügend Arbeitsspeicher" fehlschlägt, nicht die Ursache für diesen Fehler. Insgesamt können die Ursachen in drei Kategorien unterteilt werden:

Ursache 1: Arbeitsspeicherauslastung für externes Oder Betriebssystem

Externer Druck bezieht sich auf eine hohe Arbeitsspeicherauslastung durch eine Komponente außerhalb des Prozesses, die zu unzureichendem Arbeitsspeicher für SQL Server führt. Sie müssen herausfinden, ob andere Anwendungen auf dem System Arbeitsspeicher verbrauchen und zu einer geringen Speicherverfügbarkeit beitragen. SQL Server ist eine der wenigen Anwendungen, die entwickelt wurden, um auf die Arbeitsspeicherauslastung des Betriebssystems zu reagieren, indem sie die Speicherauslastung reduzieren. Dies bedeutet, dass das Betriebssystem, wenn eine Anwendung oder ein Treiber Arbeitsspeicher anfordert, ein Signal an alle Anwendungen sendet, um Arbeitsspeicher freizugeben, und SQL Server reagiert, indem es seine eigene Speicherauslastung reduziert. Nur wenige andere Anwendungen reagieren, da sie nicht darauf ausgelegt sind, auf diese Benachrichtigung zu lauschen. Wenn SQL Server daher beginnt, die Speicherauslastung zu reduzieren, wird der Speicherpool reduziert, und die Komponenten, die Arbeitsspeicher benötigen, erhalten ihn möglicherweise nicht. Daher erhalten Sie 701 oder andere speicherbezogene Fehler. Weitere Informationen dazu, wie SQL Arbeitsspeicher dynamisch zuordnet und freigibt, finden Sie unter SQL Server Arbeitsspeicherarchitektur. Ausführlichere Diagnose und Lösungen für das Problem finden Sie unter Externe Arbeitsspeicherauslastung in diesem Artikel.

Es gibt drei allgemeine Kategorien von Problemen, die zu einer Arbeitsspeicherauslastung des Betriebssystems führen können:

• Anwendungsbezogene Probleme: Eine oder mehrere Anwendungen schöpfen zusammen den verfügbaren physischen Speicher aus. Das Betriebssystem reagiert auf neue Anwendungsanforderungen für Ressourcen, indem es versucht, Arbeitsspeicher freizugeben. Der gängige Ansatz besteht darin, zu ermitteln, welche Anwendungen den Arbeitsspeicher aufgebraucht haben, und die erforderlichen Schritte zu unternehmen, um den Arbeitsspeicher zwischen ihnen auszugleichen, ohne zu einer RAM-Auslastung zu führen.
• Gerätetreiberprobleme: Gerätetreiber können eine Arbeitssatz-Paginierung aller Prozesse verursachen, wenn der Treiber fälschlicherweise eine Speicherbelegungsfunktion aufruft.
• Probleme mit dem Betriebssystemprodukt.

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

Ursache 2: Interner Speichermangel, der nicht von SQL Server

Interner Arbeitsspeichermangel bezieht sich auf eine geringe Speicherverfügbarkeit, die durch Faktoren innerhalb des SQL Server Prozesses verursacht wird. Einige Komponenten, die innerhalb des SQL Server Prozesses ausgeführt werden können, sind "extern" für die SQL Server-Engine. Beispiele hierfür sind OLE DB-Anbieter (DLLs) wie Verbindungsserver, SQLCLR-Prozeduren oder -Funktionen, erweiterte Prozeduren (XPs) und OLE-Automatisierung (sp_OA*). Andere umfassen Antiviren- oder andere Sicherheitsprogramme, die DLLs zu Überwachungszwecken in einen Prozess injizieren. Ein Problem oder ein schlechtes Design in einer dieser Komponenten kann zu einem großen Arbeitsspeicherverbrauch führen. Stellen Sie sich beispielsweise einen Verbindungsserver vor, der 20 Millionen Datenzeilen aus einer externen Quelle in SQL Server Arbeitsspeicher zwischenspeichert. Was SQL Server betrifft, meldet kein Memory Clerk eine hohe Speicherauslastung, aber der im SQL Server Prozess verbrauchte Arbeitsspeicher ist hoch. Diese Arbeitsspeichervergrößerung durch eine Verbindungsserver-DLL würde z. B. dazu führen, dass SQL Server die Speicherauslastung kürzen (siehe oben) und für Komponenten in SQL Server zu geringen Arbeitsspeicherbedingungen führt, was zu Fehlern aufgrund von unzureichendem Arbeitsspeicher führt. Ausführlichere Diagnose und Lösungen für das Problem finden Sie unter Interne Speicherauslastung, nicht aufgrund SQL Server.

Ursache 3: Interne Speicherauslastung durch SQL Server Komponente(en)

Die interne Arbeitsspeicherauslastung, die von Komponenten innerhalb der SQL Server-Engine verursacht wird, kann auch zu Fehlern aufgrund von nicht genügend Arbeitsspeicher führen. Es gibt Hunderte von Komponenten, die über Speicherbearbeiter nachverfolgt werden, die Arbeitsspeicher in SQL Server zuordnen. Sie müssen ermitteln, welche Speichermitarbeiter für die größten Speicherbelegungen verantwortlich sind, um dieses Problem zu beheben. Wenn Sie beispielsweise feststellen, dass der OBJECTSTORE_LOCK_MANAGER Speicherbearbeiter eine große Speicherbelegung anzeigt, müssen Sie verstehen, warum der Sperr-Manager so viel Arbeitsspeicher verbraucht. Möglicherweise gibt es Abfragen, die viele Sperren erhalten. Sie können diese Abfragen optimieren, indem Sie Indizes verwenden, alle Transaktionen verkürzen, die Sperren für einen längeren Zeitraum enthalten, oder überprüfen, ob die Sperrenausweitung deaktiviert ist. Jeder Speicherbearbeiter oder jede Komponente verfügt über eine einzigartige Möglichkeit, auf arbeitsspeicher zuzugreifen und diese zu verwenden. Weitere Informationen finden Sie unter Memory Clerk-Typen und deren Beschreibungen. Ausführlichere Diagnose und Lösungen zu diesem Problem finden Sie unter Interne Speicherauslastung durch SQL Server Engine.

Visuelle Darstellung der Speicherauslastungstypen

Das folgende Diagramm veranschaulicht die Arten von Druck, die zu Nicht genügend Arbeitsspeicher in SQL Server führen können:

Diagnosetools zum Sammeln von Problembehandlungsdaten

Sie können die folgenden Diagnosetools verwenden, um Daten zur Problembehandlung zu sammeln:

Systemmonitor

Konfigurieren und sammeln Sie die folgenden Leistungsindikatoren mit Leistungsmonitor:

• Arbeitsspeicher: Verfügbare MB
• Process:Working Set
• Process:Private Bytes
• SQL Server:Speicher-Manager: (alle Leistungsindikatoren)
• SQL Server:Puffer-Manager: (alle Leistungsindikatoren)

DMVs oder DBCC MEMORYSTATUS

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

Standardbericht zum Arbeitsspeicherverbrauch in SSMS

Anzeigen der Speicherauslastung in SQL Server Management Studio:

1. Starten Sie SQL Server Management Studio, und stellen Sie eine Verbindung mit einem Server her.
2. Klicken Sie in Objekt-Explorer mit der rechten Maustaste auf den Namen des SQL Server instance.
3. Wählen Sie im Kontextmenü Berichte>Standard Berichte>Arbeitsspeicherverbrauch aus.

PSSDiag oder SQL LogScout

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

• Wenn Sie PSSDiag verwenden, konfigurieren Sie es so, dass der Perfmon-Collector und der Benutzerdefinierte Diagnose\SQL-Speicherfehlersammler erfasst werden.

• Wenn Sie SQL LogScout verwenden, konfigurieren Sie es so, dass das Speicherszenario erfasst wird.

In den folgenden Abschnitten werden ausführlichere Schritte für jedes Szenario (externer oder interner Arbeitsspeichermangel) beschrieben.

Problembehandlungsmethodik

Wenn gelegentlich oder für einen kurzen Zeitraum ein Fehler mit nicht genügend Arbeitsspeicher auftritt, kann ein kurzlebiges Speicherproblem auftreten, das sich von selbst löst. Möglicherweise müssen Sie in diesen Fällen keine Maßnahmen ergreifen. Wenn der Fehler jedoch bei mehreren Verbindungen mehrmals auftritt und für mehrere Sekunden oder länger bestehen bleibt, befolgen Sie die Diagnose und Lösungen in den folgenden Abschnitten, um Speicherfehler weiter zu beheben.

Externe Speicherauslastung

Verwenden Sie die folgenden Methoden, um speicherarme Bedingungen auf dem System außerhalb des SQL Server-Prozesses zu diagnostizieren:

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

  • Arbeitsspeicher: Verfügbare MB
  • Process:Working Set
  • Process:Private Bytes

  Hier sehen Sie ein Beispiel für die Perfmon-Protokollsammlung mit 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 speicherbezogenen Fehlern (z. B. wenig virtueller Arbeitsspeicher).

• Überprüfen Sie das Anwendungsereignisprotokoll auf anwendungsbezogene Speicherprobleme.

  Hier sehen Sie ein Beispiel für ein PowerShell-Skript zum Abfragen der System- und Anwendungsereignisprotokolle für den Schlüsselwort (keyword) "Arbeitsspeicher". Sie können andere Zeichenfolgen wie "resource" 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 Speicherauslastung zu reduzieren.

• Wenn Anwendungen außer 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 externe Arbeitsspeicher nicht mehr benötigt.

Interner Speichermangel, nicht durch SQL Server

Verwenden Sie die folgenden Methoden, um die interne Speicherauslastung zu diagnostizieren, die durch Module (DLLs) in SQL Server verursacht wird:

• Wenn SQL Server keine gesperrten Seiten im Arbeitsspeicher (AWE-API) verwendet, wird der größte Teil des Arbeitsspeichers im Zähler Process:Private Bytes (SQLServr instance) in Leistungsmonitor widergespiegelt. Die Gesamtspeicherauslastung innerhalb der SQL Server-Engine wird im Leistungsindikator SQL Server:Arbeitsspeicher-Manager: Gesamter Serverarbeitsspeicher (KB) wider. Wenn Sie einen signifikanten Unterschied zwischen dem Wert Process:Private Bytes und SQL Server:Memory Manager: Total Server Memory Memory (KB) finden, stammt dieser Unterschied wahrscheinlich von einer DLL (Verbindungsserver, XP, SQLCLR usw.). Wenn private Bytes beispielsweise 300 GB und der Gesamte Serverarbeitsspeicher 250 GB beträgt, stammen ungefähr 50 GB des gesamten Arbeitsspeichers im Prozess von außerhalb der SQL Server-Engine.

• 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 Speichernutzung für einzelne Prozesse nachverfolgen. Die gesamte Arbeitsspeicherauslastung innerhalb der SQL Server-Engine wird im Leistungsindikator SQL Server:Arbeitsspeicher-Manager: Gesamter Serverarbeitsspeicher (KB) wider. Typische Process:Private Bytes-Werte können zwischen 300 MB und 1-2 GB insgesamt variieren. Wenn Sie eine erhebliche Nutzung von Process:Private Bytes finden, die über diese typische Verwendung hinausgeht, kommt der Unterschied wahrscheinlich von einer DLL (Verbindungsserver, XP, SQLCLR usw.). Wenn der Zähler private Bytes beispielsweise 4 bis 5 GB groß ist und SQL Server gesperrte Seiten im Arbeitsspeicher (AWE) verwendet, kann ein großer Teil der privaten Bytes von außerhalb der SQL Server-Engine stammen. Dies ist eine Näherungstechnik.

• Verwenden Sie das Hilfsprogramm Tasklist, um alle DLLs zu identifizieren, die in SQL Server Speicherplatz 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 Verbindungsservermodul einen erheblichen Arbeitsspeicherverbrauch verursacht, können Sie es so konfigurieren, dass der Prozess ausläuft, indem Sie die Option Inprocess zulassen deaktivieren. Weitere Informationen finden Sie unter Erstellen von Verbindungsservern . Nicht bei allen OLE DB-Verbindungsserveranbietern läuft der Prozess möglicherweise aus. Wenn Sie weitere Informationen benötigen, wenden Sie sich an den Produkthersteller.

• In den seltenen Fällen, in denen OLE-Automatisierungsobjekte (sp_OA*) verwendet werden, können Sie das Objekt so konfigurieren, dass es in einem Prozess außerhalb SQL Server ausgeführt wird, indem Sie den Kontextwert 4 angeben (nur lokaler OLE-Server (.exe). Weitere Informationen finden Sie unter sp_OACreate.

Interne Speicherauslastung durch SQL Server Engine

Verwenden Sie die folgenden Methoden, um die interne Speicherauslastung durch Komponenten innerhalb der SQL Server-Engine zu diagnostizieren:

• Beginnen Sie mit der Erfassung Leistungsmonitor Indikatoren für SQL Server: SQL Server:Puffer-Manager und SQL Server: Speicher-Manager.

• Fragen Sie den SQL Server Speicherbearbeiter-DMV mehrmals ab, um zu ermitteln, wo der höchste Speicherverbrauch innerhalb der Engine auftritt:

  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 ausführlichere DBCC MEMORYSTATUS Ausgabe und die Art und Weise beobachten, wie sie sich ändert, wenn diese Fehlermeldungen angezeigt werden.

  DBCC MEMORYSTATUS
  

• Wenn Sie einen eindeutigen Verbrecher unter den Speicherbearbeitern identifizieren, konzentrieren Sie sich auf die Besonderheiten des Arbeitsspeicherverbrauchs für diese Komponente. Es folgen einige Beispiele:

  • Wenn der Speicherbearbeiter MEMORYCLERK_SQLQERESERVATIONS Arbeitsspeicher verbraucht, identifizieren Sie Abfragen, die große Speicherzuweisungen verwenden, und optimieren Sie sie über Indizes, schreiben Sie sie neu (entfernen ORDER bySie z. B.), oder wenden Sie Abfragehinweise zur Speicherzuweisung an (siehe min_grant_percent und max_grant_percent Hinweise ). Sie können auch einen Ressourcenkontrollepool erstellen , um die Nutzung des Arbeitsspeichers für die Speicherzuweisung zu steuern. Ausführliche Informationen zu Speicherzuweisungen finden Sie unter Behandeln von Problemen mit langsamer Leistung oder unzureichendem Arbeitsspeicher, die durch Speicherzuweisungen 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 Mengen an Arbeitsspeicher verbrauchen. Identifizieren Sie nicht parametrisierte Abfragen, deren Abfragepläne nicht wiederverwendet werden können, und parametrisieren Sie sie durch Konvertieren in gespeicherte Prozeduren mit sp_executesqloder mithilfe FORCED von Parametrisierung. Wenn Sie das Ablaufverfolgungsflag 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 Mengen an Arbeitsspeicher verwenden, und gestalten Sie die Anwendung möglicherweise neu. In der Regel kann dies auf große Mengen von Datenbanken oder Schemas mit hunderten von Prozeduren zurückzuführen sein.
  • Wenn der OBJECTSTORE_LOCK_MANAGER Speicherbearbeiter große Speicherbelegungen anzeigt, identifizieren Sie Abfragen, die viele Sperren anwenden, und optimieren Sie sie mithilfe von Indizes. Verkürzen Sie Transaktionen, die dazu führen, dass Sperren in bestimmten Isolationsstufen nicht für längere Zeiträume freigegeben werden, oder überprüfen Sie, ob die Sperrenausweitung deaktiviert ist.
  • Wenn Sie sehr große TokenAndPermUserStore (select type, name, pages_kb from sys.dm_os_memory_clerks where name = 'TokenAndPermUserStore') beobachten, können Sie das Ablaufverfolgungsflag 4618 verwenden, um die Größe des Caches einzuschränken.
  • Wenn Sie Speicherprobleme mit In-Memory OLTP feststellen, die von der MEMORYCLERK_XTP Speicherverwaltung stammen, finden Sie weitere Informationen unter Überwachen und Behandeln von Problemen mit der Speicherauslastung für In-Memory OLTP und Arbeitsspeicheroptimierte tempdb-Metadaten (HkTempDB) aufgrund von Fehlern aufgrund von Arbeitsspeichermangel.

Schnelle Entlastung, die möglicherweise Arbeitsspeicher zur Verfügung stellt

Die folgenden Aktionen geben möglicherweise Speicherplatz frei und stellen ihn für SQL Server zur Verfügung:

Ändern der Speicherkonfigurationseinstellungen

Überprüfen Sie die folgenden SQL Server Speicherkonfigurationsparameter, und erwägen Sie, den maximalen Serverarbeitsspeicher nach Möglichkeit zu erhöhen:

• Max. Serverarbeitsspeicher
• Min. Serverarbeitsspeicher

Wenn Sie den maximalen Serverarbeitsspeicher nicht konfiguriert haben, insbesondere mit gesperrten Seiten im Arbeitsspeicher, sollten Sie ihn auf einen bestimmten Wert festlegen, um einen gewissen Arbeitsspeicher für das Betriebssystem zuzulassen. Weitere Informationen finden Sie unter Der Serverkonfigurationsoption Gesperrte Seiten im Arbeitsspeicher .

Ändern oder Verschieben der Workload aus dem System

Untersuchen Sie die Abfrageworkload: Anzahl gleichzeitiger Sitzungen, derzeit ausgeführte Abfragen, und überprüfen Sie, ob weniger kritische Anwendungen vorhanden sind, die möglicherweise vorübergehend beendet oder in eine andere SQL Server verschoben werden.

Für schreibgeschützte Workloads sollten Sie sie in ein schreibgeschütztes sekundäres Replikat in einer Always On-Umgebung verschieben. Weitere Informationen finden Sie unter Auslagern einer schreibgeschützten Workload auf das sekundäre Replikat einer Always On Verfügbarkeitsgruppe und Konfigurieren des schreibgeschützten Zugriffs auf ein sekundäres Replikat einer Always On Verfügbarkeitsgruppe.

Sicherstellen einer ordnungsgemäßen Arbeitsspeicherkonfiguration für virtuelle Computer

Wenn Sie SQL Server auf einem virtuellen Computer (VM) ausführen, stellen Sie sicher, dass der Arbeitsspeicher für den virtuellen Computer nicht überlasten wird. Ideen zum Konfigurieren des Arbeitsspeichers für VMs finden Sie unter Virtualisierung – Überlastung von Arbeitsspeicher und Erkennen des Arbeitsspeichers innerhalb des virtuellen Computers und Behandeln von Leistungsproblemen bei ESX/ESXi-VMs (Arbeitsspeicherüberlastung).

Freigeben von Arbeitsspeicher in SQL Server

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

• DBCC FREESYSTEMCACHE

• DBCC FREESESSIONCACHE

• DBCC FREEPROCCACHE

Neustarten SQL Server Diensts

In einigen Fällen können Sie einen Neustart des Diensts in Betracht ziehen, wenn Sie sich mit einer kritischen Speicherauslastung befassen müssen und SQL Server abfragen nicht verarbeiten können.

Erwägen der Verwendung von Resource Governor für bestimmte Szenarien

Wenn Sie Resource Governor verwenden, empfiehlt es sich, die Einstellungen des Ressourcenpools und der Arbeitsauslastungsgruppe zu überprüfen, um festzustellen, ob sie den Arbeitsspeicher nicht zu stark einschränken.

Hinzufügen von mehr RAM auf dem physischen oder virtuellen Server

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