Felsöka minnesfel med Azure SQL Database och Fabric SQL Database

2025-10-02

Gäller för:Azure SQL Database SQL-databas i Fabric

Du kan se felmeddelanden när SQL-databasmotorn inte har allokerat tillräckligt med minne för att köra frågan. Detta kan orsakas av olika orsaker, inklusive gränserna för det valda tjänstmålet, aggregerade minnesbehov för arbetsbelastningar och minnesbehov för frågan.

Mer information om minnesresursgränsen för Azure SQL Database finns i Resurshantering i Azure SQL Database. Infrastrukturresurser för SQL-databas delar många funktioner med Azure SQL Database. Mer information om prestandaövervakning finns i Prestandaövervakning av infrastrukturresurser för SQL-databaser.

Mer information om hur du felsöker minnesproblem i SQL Server finns iMSSQLSERVER_701.

Prova följande undersökningsvägar som svar på:

Felkod 701 med felmeddelandet "Det finns inte tillräckligt med systemminne i resurspoolen "%ls" för att köra den här frågan."
Felkod 802 med felmeddelandet "Det finns inte tillräckligt med minne i buffertpoolen".

Visa händelser vid minnesbrist

Om det uppstår minnesfel kan du läsa sys.dm_os_out_of_memory_events. Den här vyn innehåller information om den förutsagda orsaken till minnesbrist, som bestäms av en heuristisk algoritm och tillhandahålls med en begränsad grad av säkerhet.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Undersöka minnesallokering

Om minnesfel kvarstår i Azure SQL Database bör du överväga att åtminstone tillfälligt öka servicenivåmålet för databasen i Azure-portalen.

Om minnesfel kvarstår kan du använda följande frågor för att söka efter ovanligt höga minnesbidrag för frågor som kan bidra till ett otillräckligt minnestillstånd. Kör följande exempelfrågor i databasen som upplevde felet (inte i databasen master för den logiska Azure SQL-servern).

Använd DMV för att visa out of memory-händelser

sys.dm_os_out_of_memory_events Tillåter synlighet för händelser och orsaker till OOM-händelser (out of memory) i Azure SQL Database. Den summarized_oom_snapshot utökade händelsen är en del av den befintliga system_health händelsesessionen för att förenkla identifieringen. Mer information finns i sys.dm_os_out_of_memory_events och blogg: Ett nytt sätt att felsöka minnesfel i databasmotorn.

Använda DMV:er för att visa minnesbiträden

Om minnesfelet inträffade nyligen, börja med en bred undersökning genom att visa allokeringen av minne till minneshanterare. Minnesbiträden är interna i databasmotorn för den här Azure SQL Database. De främsta minneshanterarna när det gäller tilldelade sidor kan vara informativa för att bestämma vilken typ av fråga eller funktion i SQL Server som förbrukar mest minne.

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;

Vissa vanliga minneshanterare, till exempel MEMORYCLERK_SQLQERESERVATIONS, löses bäst genom att identifiera frågor med stora minnesackord och förbättra deras prestanda med bättre indexering och indexjustering.
Även om OBJECTSTORE_LOCK_MANAGER inte är relaterad till minnesallokeringar, förväntas den vara hög när SQL-frågor kräver många lås, till exempel på grund av inaktiverad låseskalering eller mycket stora transaktioner.
Vissa kontorister förväntas vara den högsta användningen: MEMORYCLERK_SQLBUFFERPOOL är nästan alltid den främsta kontoristen, medan CACHESTORE_COLUMNSTOREOBJECTPOOL kommer att vara hög när kolumnlagringsindex används. Högsta användning av dessa kontorister förväntas.

Mer information om typer av minnesbiträden finns i sys.dm_os_memory_clerks.

Använd DMV:er för att undersöka aktiva frågesökningar

I de flesta fall är frågan som misslyckades inte orsaken till det här felet.

Följande exempelfråga för Azure SQL Database returnerar viktig information om transaktioner som för närvarande håller eller väntar på minnesbidrag. Rikta de främsta frågorna som identifierats för undersökning och prestandaoptimering och utvärdera om de körs som avsett eller inte. Överväg tidpunkten för minnesintensiva rapporteringsfrågor eller underhållsåtgärder.

--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;

Du kan välja att använda KILL-instruktionen för att stoppa en pågående fråga som håller i eller väntar på ett stort minnesanslag. Använd den här instruktionen noggrant, särskilt när kritiska processer körs. Mer information finns i KILL (Transact-SQL).

Använda Query Store för att undersöka tidigare minnesanvändning för frågor

Medan föregående exempelfråga endast rapporterar live-frågeresultat använder följande fråga Query Store för att returnera information om tidigare frågekörning. Detta kan vara användbart när du undersöker ett minnesfel som inträffat tidigare.

Följande exempelfråga för Azure SQL Database returnerar viktig information om frågekörningar som registrerats av Query Store. Rikta de vanligaste frågeställningarna som identifierats för analys och prestandajustering, och utvärdera om de körs som avsett. Observera tidsfiltret på qsp.last_execution_time för att begränsa resultaten till nyligen historik. Du kan justera TOP-satsen för att ge mer eller färre resultat beroende på din miljö.

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;

Utökade händelser

Förutom den tidigare informationen kan det vara bra att samla in en spårning av aktiviteterna på servern för att noggrant undersöka ett problem med minnesbrist i Azure SQL Database.

Det finns två sätt att samla in spårningar i SQL Server. Extended Events (XEvents) och Profiler Traces. SQL Server Profiler är dock inaktuell spårningsteknik som inte stöds för Azure SQL Database. Extended Events är den nyare spårningstekniken som möjliggör mer mångsidighet och mindre påverkan på det observerade systemet, och dess gränssnitt är integrerat i SQL Server Management Studio (SSMS). Mer information om hur du frågar efter utökade händelser i Azure SQL Database finns i Utökade händelser i Azure SQL Database.

Se dokumentet som förklarar hur du använder guiden Förlängda händelser Ny session i SSMS. För Azure SQL-databaser tillhandahåller SSMS dock en undermapp för utökade händelser under varje databas i Object Explorer. Använd en extended events-session för att samla in dessa användbara händelser och identifiera de frågor som genererar dem:

Kategorifel:
- error_reported
- exchange_spill
- hash_spill_details
Kategoriexekvering:
- excessive_non_grant_memory_used
Minneskategori
- query_memory_grant_blocking
- query_memory_grant_usage
summarized_oom_snapshot

Insamling av minnesutdelningsblock, minnesutdelningsspill eller betydande minnesutdelningar kan vara en möjlig ledtråd till att en databegäran plötsligt tar mer minne än tidigare, och en möjlig förklaring till ett plötsligt uppkommande minnesfel i en pågående arbetsbelastning. Den summarized_oom_snapshot utökade händelsen är en del av den befintliga system_health händelsesessionen för att förenkla identifieringen. Mer information finns i Blogg: Ett nytt sätt att felsöka minnesfel i databasmotorn.

In-memory OLTP utanför minne

Du kan stöta på Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation om du använder In-Memory OLTP. Minska mängden data i minnesoptimerade tabeller och minnesoptimerade tabellvärdesparametrar, eller skala upp databasen till ett högre tjänstmål för att få mer minne. Mer information om minnesproblem med SQL Server In-Memory OLTP finns i Lösa problem med slut på minne.

Få stöd för Azure SQL Database

Om minnesfel kvarstår i Azure SQL Database skickar du en Azure-supportbegäran genom att välja Hämta support på Azure-supportwebbplatsen .

Feedback

Var den här sidan till hjälp?