Felsöka minnesfel (slut på minne) med Azure SQL Database

  • Artikel

Gäller för:Azure SQL Database

Du kan se felmeddelanden när SQL-databasmotorn inte har allokerat tillräckligt med minne för att köra frågan. Detta kan bero på olika orsaker, som exempelvis gränserna för det valda tjänstmålet, aggregerade krav på arbetsbelastningsminne och minneskrav för frågan. Mer information om minnesresursgränsen för Azure SQL-databaser finns i Resurshantering i Azure SQL Database.

Kommentar

Den här artikeln fokuserar på Azure SQL Database. Mer information om hur du felsöker minnesproblem i SQL Server finns i MSSQLSERVER_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 minneshändelser

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 minnesorsaken, som bestäms av en heuristisk algoritm och tillhandahålls med en begränsad grad av förtroende.

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ända DMV för att visa minneshä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

Börja med en bred undersökning, om felet om slut på minne inträffade nyligen, genom att visa allokeringen av minne till minnesbiträden. Minnesbiträden är interna i databasmotorn för den här Azure SQL Database. De främsta minneskontoren när det gäller tilldelade sidor kan vara informativa för 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 minnesbiträden, till exempel MEMORYCLERK_SQLQERESERVATIONS, löses bäst genom att identifiera frågor med stora minnesbidrag och förbättra deras prestanda med bättre indexering och indexjustering.
  • Även om OBJECTSTORE_LOCK_MANAGER inte är relaterat till minnesbidrag förväntas det vara högt när 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ända DMV:er för att undersöka aktiva frågor

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 vanligaste frågorna som identifierats för undersökning och prestandajustering 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 fråga som körs just nu och som håller i eller väntar på ett stort minnesbidrag. 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ågorna som identifierats för undersökning och prestandajustering och utvärdera om de körs som avsett eller inte. Observera tidsfiltret för qsp.last_execution_time att begränsa resultatet till den senaste historiken. 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

  • Kategorikörning:

    • excessive_non_grant_memory_used

  • Kategoriminne:

    • query_memory_grant_blocking
    • query_memory_grant_usage

  • summarized_oom_snapshot

    Insamling av minnesbidragsblock, minnesbidragsspill eller stora minnesbidrag kan vara en möjlig ledtråd till att en fråga plötsligt tar mer minne än tidigare, och en möjlig förklaring till ett framväxande minnesfel i en befintlig 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.

Minnesintern OLTP slut på 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 minnesintern 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 problem med minnesbrist med SQL Server Minnesintern 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.

Relaterat innehåll