MSSQLSERVER_701

Artikel
03/25/2023

Details

attribute	Wert
Produktname	SQL Server
Ereignis-ID	701
Ereignisquelle	MSSQLSERVER
Komponente	SQLEngine
Symbolischer Name	NOSYSMEM
Meldungstext	Es ist nicht genügend Systemarbeitsspeicher zum Ausführen dieser Abfrage vorhanden.

Hinweis

Dieser Artikel ist auf SQL Server ausgelegt. Informationen zur Behandlung von Problemen mit unzureichendem Arbeitsspeicher in Azure SQL-Datenbank finden Sie unter Beheben von Fehlern aufgrund von unzureichendem Arbeitsspeicher in Azure SQL-Datenbank.

Erklärung

Fehler 701 tritt auf, wenn SQL Server nicht genügend Arbeitsspeicher für die Ausführung einer Abfrage zuweisen konnte. Unzureichender Arbeitsspeicher kann durch eine Reihe von Faktoren verursacht werden (z. B. Betriebssystemeinstellungen, Verfügbarkeit des physischen Speichers, Nutzung des Arbeitsspeichers innerhalb von SQL Server durch andere Komponenten oder Arbeitsspeicherlimits für die aktuelle Workload). In den meisten Fällen ist der Fehler nicht auf die nicht erfolgreiche Transaktion zurückzuführen. Insgesamt können die Ursachen in drei Gruppen unterteilt werden:

Externe Arbeitsspeicherauslastung oder Auslastung des Betriebssystemspeichers

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 ermitteln, ob andere Anwendungen im System Arbeitsspeicher verbrauchen und zu geringer Arbeitsspeicherverfügbarkeit beitragen. SQL Server ist eine der wenigen Anwendungen, die darauf ausgelegt sind, auf die Auslastung des Betriebssystemspeichers zu reagieren, indem die Speicherauslastung eingeschränkt wird. Wenn also eine Anwendung oder ein Treiber Arbeitsspeicher anfordert, sendet das Betriebssystem ein Signal an alle Anwendungen, um Arbeitsspeicher freizugeben, und SQL Server reduziert die eigene Speicherauslastung. Nur sehr wenige andere Anwendungen reagieren in solchen Fällen, da sie nicht dafür konzipiert sind, auf diese Benachrichtigung zu lauschen. Wenn also SQL damit beginnt, die Arbeitsspeicherauslastung zu verringern, wird der Speicherpool reduziert, und die Komponenten, die Arbeitsspeicher benötigen, erhalten diesen möglicherweise nicht. Sie erhalten den Fehler 701 und andere speicherbezogene Fehler. Weitere Informationen finden Sie unter SQL Server-Arbeitsspeicherarchitektur.

Interne Arbeitsspeicherauslastung, die nicht durch SQL Server verursacht wird

Die interne Arbeitsspeicherauslastung bezieht sich auf eine geringe Arbeitsspeicherverfügbarkeit, die durch Faktoren innerhalb des SQL Server-Prozesses verursacht wird. Es gibt Komponenten, die innerhalb des SQL Server-Prozesses ausgeführt werden können, die für die SQL Server-Engine „extern“ sind. Beispiele hierfür sind DLLs wie Verbindungsserver, SQLCLR-Komponenten, erweiterte Prozeduren (XPs) und die 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 Verbindungsserver kann 20 Millionen Datenzeilen aus einer externen Quelle in SQL Server-Arbeitsspeicher zwischenspeichern. Was SQL Server betrifft, meldet kein Arbeitsspeicherclerk eine hohe Arbeitsspeicherauslastung, aber der im SQL Server-Prozess verbrauchte Arbeitsspeicher ist hoch. Diese steigende Arbeitsspeicherauslastung durch die DLL eines Verbindungsservers würde beispielsweise dazu führen, dass SQL Server damit beginnt, die Arbeitsspeicherauslastung (siehe oben) zu reduzieren und für Komponenten innerhalb von SQL Server Bedingungen für geringen Arbeitsspeicher zu erstellen, was zu Fehlern wie Fehler 701 führt.

Interne Arbeitsspeicherauslastung, die durch SQL Server-Komponenten verursacht wird

Die interne Arbeitsspeicherauslastung durch Komponenten innerhalb der SQL Server-Engine kann auch zu Fehler 701 führen. Es gibt Hunderte von Komponenten, die über Arbeitsspeicherclerks nachverfolgt werden, die Arbeitsspeicher in SQL Server zuordnen. Sie müssen ermitteln, welche Arbeitsspeicherclerks für die größten Speicherbelegungen verantwortlich sind, um dies weiter korrigieren zu können. Wenn der Arbeitsspeicherclerk „OBJECTSTORE_LOCK_MANAGER“ beispielsweise eine hohe Speicherbelegung anzeigt, müssen Sie herausfinden, warum der Sperren-Manager so viel Arbeitsspeicher verbraucht. Möglicherweise gibt es Abfragen, die eine große Anzahl von Sperren abrufen und diese mithilfe von Indizes optimieren, Transaktionen mit Sperren für längere Zeiträume verkürzen oder Überprüfungen durchführen, ob die Sperrenausweitung 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.

Benutzeraktion

Wenn Fehler 701 gelegentlich oder für einen kurzen Zeitraum auftritt, kann ein kurzlebiges Speicherproblem vorliegen, das automatisch behoben wird. In diesen Fällen müssen Sie möglicherweise keine Maßnahmen ergreifen. Wenn der Fehler jedoch mehrmals bei mehreren Verbindungen auftritt und über einen Zeitraum von mehreren Sekunden oder länger vorliegt, führen Sie die Schritte zur weiteren Problembehandlung aus.

In der folgenden Liste werden allgemeine Schritte erläutert, die bei der Problembehandlung von Arbeitsspeicherfehlern helfen.

Diagnosetools und Erfassung

Die Diagnosetools, mit denen Sie Problembehandlungsdaten sammeln können, sind die Leistungsüberwachung, sys.dm_os_memory_clerks und DBCC MEMORYSTATUS .

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

Memory:Available MB
Process:Working Set
Process:Private Bytes
SQL Server:Memory Manager: (alle Leistungsindikatoren)
SQL Server:Buffer Manager: (alle Leistungsindikatoren)

Sammeln Sie periodische Ausgaben dieser Abfrage für die betroffene SQL Server-Instanz.

SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC

„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 das Tool für die Erfassung der Collectors Perfmon und Custom Diagnostics\SQL Memory Error.
Wenn Sie „SQL LogScout“ verwenden, konfigurieren Sie die Erfassung des Szenarios Memory.

In den folgenden Abschnitten werden ausführlichere Schritte für jedes Szenario beschrieben: externe oder interne Arbeitsspeicherauslastung.

Externe Arbeitsspeicherauslastung: Diagnose und Lösungen

Erfassen Sie die Leistungsindikatoren der Leistungsüberwachung, um geringe Arbeitsspeicherbedingungen im System außerhalb des SQL Server-Prozesses zu diagnostizieren. Untersuchen Sie anhand der folgenden Leistungsindikatoren, ob andere Anwendungen oder Dienste als SQL Server Arbeitsspeicher auf diesem Server verbrauchen:
- Memory:Available MB
- Process:Working Set
- Process:Private Bytes
Hier sehen Sie eine Beispiel-Perfmon-Protokollsammlung 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 sehen Sie ein PowerShell-Beispielskript zum Abfragen der System- und Applicaiton-Ereignisprotokolle nach dem 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 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 Mangel an externem Arbeitsspeicher beseitigt.

Interne Arbeitsspeicherauslastung, die nicht durch SQL Server verursacht wird: Diagnose und Lösungen

Verwenden Sie den folgenden Ansatz, um die interne Arbeitsspeicherauslastung zu diagnostizieren, die durch Module (DLLs) innerhalb von SQL Server verursacht wird:

Wenn SQL Server die Option Seiten im Arbeitsspeicher sperren (AWE-API) nicht verwendet, wird der größte Teil des Arbeitsspeichers im Leistungsindikator Process:Private Bytes (SQLServr-Instanz) in der Leistungsüberwachung widergespiegelt. Die gesamte Arbeitsspeicherauslastung durch Komponenten innerhalb der SQL Server-Engine wird mit dem Leistungsindikator SQL Server:Memory Manager: Total Server Memory (KB) dargestellt. Wenn zwischen den Werten für Process:Private Bytes und SQL Server:Memory Manager: Total Server Memory (KB) ein erheblicher Unterschied besteht, wird dieser wahrscheinlich von einer DLL (Verbindungsserver, XP, SQLCLR usw.) verursacht. Wenn Private bytes beispielsweise 300 GB und Total Server Memory 250 GB betragen, werden ungefähr 50 GB des gesamten Arbeitsspeichers im Prozess von Komponenten außerhalb der SQL Server-Engine belegt.
Wenn SQL Server die Option „Seiten im Arbeitsspeicher sperren“ (AWE-API) verwendet, ist es schwieriger, das Problem zu identifizieren, da die Leistungsüberwachung keine AWE-Leistungsindikatoren bietet, die die Speicherauslastung für einzelne Prozesse nachverfolgen. Die gesamte Arbeitsspeicherauslastung durch Komponenten innerhalb der SQL Server-Engine wird mit dem Leistungsindikator SQL Server:Memory Manager: Total Server Memory (KB) dargestellt. Typische Werte für Process:Private Bytes können zwischen 300 MB und 1 bis 2 GB insgesamt variieren. Wenn die Nutzung von Process:Private Bytes erheblich über der typischen Nutzung liegt, wird der Unterschied wahrscheinlich von einer DLL (Verbindungsserver, XP, SQLCLR usw.) verursacht. Wenn der Leistungsindikator für Private bytes zwischen 4 und 5 GB liegt und SQL Server die Option „Seiten im Arbeitsspeicher sperren“ (AWE) verwendet, wird möglicherweise ein großer Teil von „Private bytes“ von Komponenten außerhalb der SQL Server-Engine beansprucht. 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 diese Abfrage auch verwenden, um geladene Module (DLLs) zu untersuchen und zu überprüfen, ob eine nicht erwartete Komponente 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 es außerhalb des Prozesses ausgeführt wird, indem Sie die Option InProcess zulassen deaktivieren. Weitere Informationen finden Sie unter Erstellen von Verbindungsservern. Nicht alle Verbindungsserver von OLEDB-Anbietern können außerhalb des Prozesses ausgeführt werden. Wenden Sie sich an den Produkthersteller, um weitere Informationen zu erhalten.
In dem seltenen Fall, dass OLE-Automatisierungsobjekte verwendet werden (sp_OA*), können Sie das Objekt so konfigurieren, dass es in einem Prozess außerhalb von SQL Server ausgeführt wird, indem Sie context auf „4“ (nur lokale OLE-Server (EXE)) festlegen. Weitere Informationen finden Sie unter sp_OACreate.

Interne Arbeitsspeicherauslastung, die durch die SQL Server-Engine verursacht wird: Diagnose und Lösungen

Beginnen Sie mit der Erfassung von Leistungsüberwachungsindikatoren für SQL Server:SQL Server:Buffer Manager, 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 ausführlichere DBCC MEMORYSTATUS-Ausgabe überprüfen und 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 Arbeitsspeicherclerk „MEMORYCLERK_SQLQERESERVATIONS“ Arbeitsspeicher verbraucht, identifizieren Sie Abfragen, die große Arbeitsspeicherzuweisungen verwenden. Optimieren Sie diese mithilfe von Indizes, schreiben Sie sie neu (z. B. durch Entfernen von „ORDER“), oder wenden Sie Abfragehinweise an.
- 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 entweder durch Konvertieren in gespeicherte Prozeduren, mithilfe von sp_executesql oder mithilfe der FORCED-Parametrisierung.
- Wenn der Cachespeicher des Objektplans „CACHESTORE_OBJCP“ viel Arbeitsspeicher verbraucht, gehen Sie wie folgt vor: Ermitteln Sie, welche gespeicherten Prozeduren, Funktionen oder Trigger viel Arbeitsspeicher verwenden, und gestalten Sie die Anwendung möglicherweise neu. Dies kann häufig durch große Mengen von Datenbanken oder Schemas mit jeweils Hunderten von Prozeduren verursacht werden.
- Wenn der Arbeitsspeicherclerk „OBJECTSTORE_LOCK_MANAGER“ die großen Arbeitsspeicherzuordnungen anzeigt, identifizieren Sie Abfragen, die viele Sperren anwenden, und optimieren Sie sie mithilfe von Indizes. Kürzen Sie Transaktionen, die dazu führen, dass Sperren für längere Zeiträume in bestimmten Isolationsstufen nicht aufgehoben werden, oder überprüfen Sie, ob die Sperrenausweitung deaktiviert ist.

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

Die folgenden Aktionen können speicherfrei und für SQL Server verfügbar machen:

Ü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
  
  Achten Sie auf ungewöhnliche Einstellungen. Berichtigen Sie sie bei Bedarf. Konto für erhöhte Arbeitsspeicheranforderungen. Die Standardeinstellungen sind unter Konfigurationsoptionen für den Serverarbeitsspeicher aufgeführt.
Wenn Sie Max. Serverarbeitsspeicher nicht konfiguriert haben (insbesondere bei „Seiten im Arbeitsspeicher sperren“), sollten Sie erwägen, einen bestimmten Wert festzulegen, um einen Teil des Arbeitsspeichers für das Betriebssystem bereitzustellen. Weitere Informationen finden Sie im Artikel zur Serverkonfigurationsoption Seiten im Arbeitsspeicher sperren.
Überprüfen Sie die Abfragearbeitsauslastung und die Anzahl gleichzeitiger Sitzungen, die derzeit Abfragen ausführen. Ermitteln Sie, ob weniger kritische Anwendungen vorhanden sind, die vorübergehend beendet werden oder in eine andere SQL Server-Instanz verschoben werden.
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 von Arbeitsspeicher für VMs finden Sie in diesem Blog Virtualisierung – Überlastung des Arbeitsspeichers und wie Sie ihn innerhalb des virtuellen Computers erkennen und Probleme mit der Leistung virtueller ESX/ESXi-Computer behandeln (Speicherüberlastung).
Sie können die folgenden DBCC-Befehle ausführen, um mehrere SQL Server Arbeitsspeichercaches freizugeben.
- DBCC FREESYSTEMCACHE
- DBCC FREESESSIONCACHE
- DBCC FREEPROCCACHE
Bei Verwendung des Resource Governor empfiehlt es sich, die Einstellungen des Ressourcenpools oder der Arbeitsauslastungsgruppe zu überprüfen und zu ermitteln, ob sie den Arbeitsspeicher nicht zu stark einschränken.
Wenn das Problem weiterhin auftritt, müssen Sie es genauer untersuchen und möglicherweise die Serverressourcen erhöhen (RAM).