Beheben von Arbeitsspeicherfehlern mit Azure SQL Database- und Fabric SQL-Datenbank

Gilt für:Azure SQL Database SQL-Datenbank in Fabric

Möglicherweise werden Fehlermeldungen angezeigt, wenn die SQL Datenbank-Engine nicht genügend Arbeitsspeicher zum Ausführen der Abfrage zuteilen konnte. Dies kann verschiedene Ursachen haben, z. B. die Grenzwerte des ausgewählten Dienstziels, die aggregierten Arbeitsspeicheranforderungen der Workload und die Arbeitsspeicheranforderungen durch die Abfrage.

Weitere Informationen zum Speicherressourcengrenzwert für Azure SQL Database finden Sie unter Ressourcenverwaltung in Azure SQL Database. Fabric SQL-Datenbank teilt viele Features mit Azure SQL Database, weitere Informationen zur Leistungsüberwachung finden Sie unter Fabric SQL-Datenbankleistungsüberwachung.

Weitere Informationen zur Problembehandlung bei Nichtspeicherproblemen in SQL Server finden Sie unter MSSQLSERVER_701.

Probieren Sie die folgenden Untersuchungsmöglichkeiten aus, wenn die nachfolgenden Fehler auftreten:

Fehlercode 701 mit der Fehlermeldung „Es ist nicht genügend Systemspeicher im Ressourcenpool '%ls' zum Ausführen dieser Abfrage verfügbar.“
Fehlercode 802 mit der Fehlermeldung „Im Pufferpool ist nicht genügend Arbeitsspeicher verfügbar.“

Anzeigen von Arbeitsspeichermangel-Ereignissen

Wenn Fehler wegen Arbeitsspeichermangel auftreten, überprüfen Sie sys.dm_os_out_of_memory_events. Diese Ansicht enthält Informationen zur vorhergesagten Ursache für den Arbeitsspeicherengpass, die durch einen heuristischen Algorithmus bestimmt wird und mit einem begrenzten Maß an Sicherheit bereitgestellt wird.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Speicherbelegung untersuchen

Wenn Speichermangel-Fehler in Azure SQL Database weiterhin auftreten, sollten Sie erwägen, mindestens vorübergehend das Dienstleistungsziel der Datenbank im Azure-Portal zu erhöhen.

Wenn weiterhin Fehler aufgrund von nicht genügend Arbeitsspeicher auftreten, verwenden Sie die folgenden Abfragen, um nach ungewöhnlich hohen Abfragespeicherzuweisungen zu suchen, die zu einer unzureichenden Arbeitsspeicherbedingung beitragen können. Führen Sie die folgenden Beispielabfragen in der Datenbank aus, bei denen der Fehler aufgetreten ist (nicht in der Datenbank master des logischen Servers Azure SQL).

Verwenden Sie DMV, um Out-of-Memory-Ereignisse anzuzeigen

Die sys.dm_os_out_of_memory_events ermöglicht die Sichtbarkeit der Ereignisse und Ursachen von OOM-Ereignissen (Out of Memory) in Azure SQL Database. Das erweiterte summarized_oom_snapshot-Ereignis ist Teil der bestehenden system_health-Ereignissitzung und soll die Erkennung vereinfachen. Weitere Informationen finden Sie unter sys.dm_os_out_of_memory_events und im Blog: Eine neue Möglichkeit zur Problembehandlung bei nicht genügend Arbeitsspeicher in der Datenbank-Engine.

Verwenden Sie DMVs, um Arbeitsspeicher-Clerks anzuzeigen

Beginnen Sie mit einer umfassenden Untersuchung, wenn der Fehler „Nicht genügend Arbeitsspeicher“ kürzlich aufgetreten ist, indem Sie die Speicherbelegung für Arbeitsspeicher-Clerks anzeigen. Speicherverwaltungseinheiten sind intern im Datenbankmodul für diese Azure SQL-Datenbank. Die wichtigsten Speicherbearbeiter in Bezug auf die zugeordneten Seiten können informativ sein, welche Art von Abfrage oder Feature von SQL Server den meisten Arbeitsspeicher verbraucht.

SELECT [type], [name], pages_kb, virtual_memory_committed_kb
FROM sys.dm_os_memory_clerks
WHERE memory_node_id <> 64 -- ignore Dedicated Admin Connection (DAC) node
ORDER BY pages_kb DESC;
GO
SELECT [type], [name], pages_kb, virtual_memory_committed_kb
FROM sys.dm_os_memory_clerks
WHERE memory_node_id <> 64 -- ignore Dedicated Admin Connection (DAC) node
ORDER BY virtual_memory_committed_kb DESC;

Einige gängige Arbeitsspeicher-Clerks, z. B. MEMORYCLERK_SQLQERESERVATIONS, lassen sich am besten lösen, indem Abfragen mit großen Speicherzuweisungen identifiziert und deren Leistung durch bessere Indizierung und Indexoptimierung verbessert wird.
Obwohl OBJECTSTORE_LOCK_MANAGER nicht mit Speicherzuweisungen zu tun hat, ist zu erwarten, dass dieser hoch ist, wenn Abfragen viele Sperren beanspruchen, z. B. aufgrund einer deaktivierten Sperreneskalierung oder sehr großer Transaktionen.
Es ist zu erwarten, dass einige Clerks die höchste Auslastung haben: MEMORYCLERK_SQLBUFFERPOOL ist fast immer der oberste Clerk, während CACHESTORE_COLUMNSTOREOBJECTPOOL hoch ist, wenn Columnstore-Indizes verwendet werden. Die höchste Auslastung durch diese Clerks wird erwartet.

Weitere Informationen zu Arbeitsspeicherverwaltertypen finden Sie unter sys.dm_os_memory_clerks.

Verwenden Sie DMVs, um aktive Abfragen zu untersuchen.

In den meisten Fällen ist die fehlgeschlagene Abfrage nicht die Ursache dieses Fehlers.

Die folgende Beispielabfrage für Azure SQL Database gibt wichtige Informationen zu Transaktionen zurück, die aktuell halten oder auf Speichererteilung warten. Konzentrieren Sie sich auf die wichtigsten Abfragen, die für die Untersuchung und Leistungsoptimierung identifiziert wurden, und bewerten Sie, ob sie wie beabsichtigt ausgeführt werden. Berücksichtigen Sie die Termine von speicherintensiven Berichtsabfragen oder Wartungsvorgängen.

--Active requests with memory grants
SELECT
--Session data 
  s.[session_id], s.open_transaction_count
--Memory usage
, r.granted_query_memory, mg.grant_time, mg.requested_memory_kb, mg.granted_memory_kb
, mg.required_memory_kb, mg.used_memory_kb, mg.max_used_memory_kb     
--Query 
, query_text = t.text, input_buffer = ib.event_info, query_plan_xml = qp.query_plan
, request_row_count = r.row_count, session_row_count = s.row_count
--Session history and status
, s.last_request_start_time, s.last_request_end_time, s.reads, s.writes, s.logical_reads
, session_status = s.[status], request_status = r.status
--Session connection information
, s.host_name, s.program_name, s.login_name, s.client_interface_name, s.is_user_process
FROM sys.dm_exec_sessions s 
LEFT OUTER JOIN sys.dm_exec_requests AS r 
    ON r.[session_id] = s.[session_id]
LEFT OUTER JOIN sys.dm_exec_query_memory_grants AS mg 
    ON mg.[session_id] = s.[session_id]
OUTER APPLY sys.dm_exec_sql_text (r.[sql_handle]) AS t
OUTER APPLY sys.dm_exec_input_buffer(s.[session_id], NULL) AS ib 
OUTER APPLY sys.dm_exec_query_plan (r.[plan_handle]) AS qp 
WHERE mg.granted_memory_kb > 0
ORDER BY mg.granted_memory_kb desc, mg.requested_memory_kb desc;

Sie können die KILL-Anweisung verwenden, um eine aktuell ausgeführte Abfrage zu beenden, die eine große Speicherzuweisung enthält oder darauf wartet. Verwenden Sie diese Anweisung vorsichtig, besonders wenn gerade kritische Prozesse ausgeführt werden. Weitere Informationen finden Sie unter KILL (Transact-SQL).

Verwenden von Query Store, um die Speicherauslastung früherer Abfragen zu untersuchen

Während in den vorherigen Beispielabfragen nur Live-Abfrageergebnisse gemeldet werden, verwendet die folgende Abfrage die Query Store, um Informationen zur letzten Abfrageausführung zurückzugeben. Dies kann bei der Untersuchung eines Speichermangels hilfreich sein, der in der Vergangenheit aufgetreten ist.

Die folgende Beispielabfrage für Azure SQL Database gibt wichtige Informationen zu Abfrageausführungen zurück, die vom Query Store aufgezeichnet werden. Konzentrieren Sie sich auf die wichtigsten Abfragen, die für die Untersuchung und Leistungsoptimierung identifiziert wurden, und bewerten Sie, ob sie wie beabsichtigt ausgeführt werden. Beachten Sie den Zeitfilter für qsp.last_execution_time, um die Ergebnisse auf den letzten Verlauf zu beschränken. Sie können die TOP-Klausel anpassen, um je nach Umgebung mehr oder weniger Ergebnisse zu erhalten.

SELECT TOP 10 PERCENT --limit results
  a.plan_id, query_id, plan_group_id, query_sql_text
, query_plan = TRY_CAST(query_plan as XML)
, avg_query_max_used_memory
, min_query_max_used_memory
, max_query_max_used_memory
, last_query_max_used_memory 
, last_execution_time  
, query_count_executions
    FROM (
    SELECT 
      qsp.plan_id, qsp.query_id, qsp.plan_group_id, qsp.query_plan, qsqt.query_sql_text
    , last_execution_time = MAX(qsp.last_execution_time)
    , query_count_executions = SUM(qsrs.count_executions) 
    , avg_query_max_used_memory = AVG(qsrs.avg_query_max_used_memory)
    , min_query_max_used_memory = MIN(qsrs.min_query_max_used_memory)
    , max_query_max_used_memory = MAX(qsrs.max_query_max_used_memory)
    , last_query_max_used_memory = MAX(qsrs_latest.last_query_max_used_memory) --only from latest result
    FROM sys.query_store_plan AS qsp 
    INNER JOIN sys.query_store_query AS qsq
        ON qsp.query_id = qsq.query_id
    INNER JOIN sys.query_store_query_text AS qsqt
        ON qsq.query_text_id = qsqt.query_text_id 
    INNER JOIN sys.query_store_runtime_stats AS qsrs
        ON qsp.plan_id = qsrs.plan_id 
    INNER JOIN (SELECT plan_id
            , last_query_max_used_memory 
            , rownum = ROW_NUMBER() OVER (PARTITION BY plan_id ORDER BY last_execution_time DESC)
            FROM sys.query_store_runtime_stats qsrs) AS qsrs_latest
        ON qsrs_latest.plan_id = qsp.plan_id
        AND qsrs_latest.rownum = 1 --use latest last_query_max_used_memory per plan_id
    WHERE DATEADD(hour, -24, sysdatetime()) < qsp.last_execution_time --past 24 hours only
    AND qsrs_latest.last_query_max_used_memory > 0
    GROUP BY qsp.plan_id, qsp.query_id, qsp.plan_group_id, qsp.query_plan, qsqt.query_sql_text
    ) AS a
ORDER BY max_query_max_used_memory DESC, avg_query_max_used_memory DESC;

Erweiterte Ereignisse

Zusätzlich zu den vorherigen Informationen kann es hilfreich sein, eine Ablaufverfolgung der Aktivitäten auf dem Server zu erfassen, um ein Speicherproblem im Azure SQL Database gründlich zu untersuchen.

Es gibt zwei Möglichkeiten, Ablaufverfolgungen in SQL Server zu erfassen; Erweiterte Ereignisse (XEvents) und Profiler-Ablaufverfolgungen. SQL Server Profiler ist jedoch eine veraltete Ablaufverfolgungstechnologie, die für Azure SQL-Datenbank nicht unterstützt wird. Extended Events ist die neuere Ablaufverfolgungstechnologie, die mehr Vielseitigkeit und weniger Auswirkungen auf das beobachtete System ermöglicht und seine Schnittstelle in SQL Server Management Studio (SSMS) integriert ist. Weitere Informationen dazu, wie erweiterte Ereignisse in Azure SQL Database abgefragt werden können, finden Sie unter Extended events in Azure SQL Database.

Lesen Sie das Dokument, in dem die Verwendung des Assistenten für neue Sitzungen für erweiterte Ereignisse in SSMS erläutert wird. Für Azure SQL Datenbanken stellt SSMS jedoch unter jeder Datenbank in Object Explorer einen Unterordner für erweiterte Ereignisse bereit. Verwenden Sie eine Sitzung für erweiterte Ereignisse, um diese nützlichen Ereignisse zu erfassen und die Abfragen zu identifizieren, die sie generieren:

Kategorie Fehler:
- error_reported
- exchange_spill
- hash_spill_details
Kategorie „Ausführung“:
- excessive_non_grant_memory_used
Kategoriespeicher:
- query_memory_grant_blocking
- query_memory_grant_usage
summarized_oom_snapshot

Die Erfassung von Speicherzuweisungsblöcken, Speicherzuweisungsüberläufen oder übermäßige Speicherzuweisungen kann ein potenzieller Hinweis darauf sein, dass eine Abfrage plötzlich mehr Arbeitsspeicher als in der Vergangenheit benutzt, und eine mögliche Erklärung für einen aufgetretenen „Nicht genügend Arbeitsspeicher“-Fehler in einer vorhandenen Workload sein. Das erweiterte summarized_oom_snapshot-Ereignis ist Teil der bestehenden system_health-Ereignissitzung und soll die Erkennung vereinfachen. Weitere Informationen finden Sie im Blog: Eine neue Möglichkeit zur Problembehandlung bei unzureichendem Arbeitsspeicher in der Datenbank-Engine.

In-Memory-OLTP Speicherplatz erschöpft

Bei Verwendung von In-Memory-OLTP kann Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation auftreten. Reduzieren Sie die Datenmenge in speicheroptimierten Tabellen und speicheroptimierten Tabellenwertparametern, oder skalieren Sie die Datenbank auf ein höheres Dienstziel hoch, um mehr Arbeitsspeicher zu erhalten. Weitere Informationen zu Problemen mit unzureichendem Speicher bei SQL Server In-Memory OLTP finden Sie unter Beheben von Problemen mit unzureichendem Speicher.

Azure SQL Database Support erhalten

Wenn Speicherfehler in Azure SQL-Datenbank weiterhin auftreten, stellen Sie eine Azure-Support-Anfrage, indem Sie Get Support auf der Azure Support-Website auswählen.

Feedback

War diese Seite hilfreich?

Last updated on 2026-03-12