MSSQLSERVER_701

Artikel
06/14/2024

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 zuweisen konnte, um eine Abfrage auszuführen. 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 SQL also mit dem Kürzen der Speicherauslastung beginnt, wird der Speicherpool reduziert, und welche Komponenten Arbeitsspeicher benötigen, wird möglicherweise nicht abgerufen. 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 "extern" für das SQL Server-Modul 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 sys.dm_os_memory_clerks nachverfolgt werden, die Speicher 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 mithilfe von Indizes optimieren oder Transaktionen verkürzen, die Sperren für lange Zeiträume halten, 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 finden Sie unter sys.dm_os_memory_clerks und deren Beschreibungen.

Aktion des Benutzers

Wenn fehler 701 gelegentlich oder für einen kurzen Zeitraum angezeigt wird, liegt möglicherweise ein kurzlebiges Speicherproblem vor, das sich selbst behoben hat. 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 regelmäßiger Ausgaben dieser Abfrage für den betroffenen SQL Server

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 ist eine Perfmon-Beispielprotokollsammlung 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 Fehlern in Bezug auf den Arbeitsspeicher (z. B. zu wenig virtueller Arbeitsspeicher).
Überprüfen Sie das Anwendungsereignisprotokoll auf anwendungsbezogene Speicherprobleme.

Hier ist ein PowerShell-Beispielskript 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: 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 Sperrseiten in der Speicheroption (AWE-API) nicht verwendet, wird der größte Teil des Speichers im Prozess:Private Bytes-Leistungsindikator (SQLServrInstanz) in Leistungsmonitor angezeigt. 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 Sperrseiten im Arbeitsspeicher (AWE-API) verwendet, ist es schwieriger, das Problem zu identifizieren, da der Leistungsmonitor 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 insgesamt 1-2 GB 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 Zähler für private Bytes beispielsweise 5-4 GB beträgt und SQL Server Sperrseiten 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 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 verknüpften Servern (SQL Server Datenbank-Engine). Nicht alle verknüpften Server OLEDB-Anbieter laufen aus dem Prozess; wenden Sie sich an den Produkthersteller, um weitere Informationen zu erfahren.
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 den Kontext = 4 (nur lokale (.exe) OLE-Server 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 Speichermengen verwenden. Identifizieren Sie nicht parametrisierte Abfragen, deren Abfragepläne nicht wiederverwendet und parametrisiert werden können, indem Sie entweder in gespeicherte Prozeduren oder mithilfe sp_executesqlder FORCED-Parameterisierung konvertieren.
- 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 an Datenbanken oder Schemas mit hunderten von Prozeduren auftreten.
- 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 Erleichterung, die Speicher verfügbar machen kann

Die folgenden Aktionen können Arbeitsspeicher freigeben und sql Server zur Verfügung stellen:

Ü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 nicht den maximalen Serverspeicher konfiguriert haben, insbesondere bei Sperrseiten im Arbeitsspeicher, sollten Sie die Einstellung auf einen bestimmten Wert erwägen, um Arbeitsspeicher für das Betriebssystem zuzulassen. Siehe Option "Seiten sperren" in der Konfigurationsoption "Speicherserver ".
Überprüfen Sie die Abfrageworkload: Anzahl der gleichzeitigen Sitzungen, die derzeit Abfragen ausführen und überprüfen, ob weniger kritische Anwendungen vorhanden sind, die vorübergehend beendet oder auf einen anderen SQL Server verschoben werden können.
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. Informationen zum Konfigurieren des Arbeitsspeichers für VMs finden Sie im Blogbeitrag Virtualisierung: Informationen zur Arbeitsspeicherüberlastung und deren Ermittlung auf einer VM und im Artikel zur Behandlung von Leistungsproblemen von virtuellen ESX/ESXi-Computern (Arbeitsspeicherüberlastung).
Sie können die folgenden DBCC-Befehle ausführen, um mehrere SQL Server-Speichercaches 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).

Freigeben über