Odstraňování chyb nedostatku paměti u databáze Azure SQL Database a Fabric SQL database

Applies to:Azure SQL DatabaseSQL database in Fabric

Mohou se zobrazit chybové zprávy, pokud se databázovému stroji SQL nepodaří přidělit dostatek paměti ke spuštění dotazu. To může být způsobeno různými příčinami, včetně limitů zvoleného cíle služby, agregovanými požadavky na paměť úlohy a požadavky na paměť, které má dotaz.

Další informace o limitu prostředků paměti pro Azure SQL Database najdete v tématu Správa zdroje v Azure SQL Database. Databáze SQL Fabric sdílí mnoho funkcí s Azure SQL Database, další informace o monitorování výkonu najdete v tématu Monitorování výkonu databáze SQLFabric.

Další informace o řešení potíží s nedostatkem paměti v SQL Server najdete v tématu MSSQLSERVER_701.

Vyzkoušejte následující způsoby šetření v reakci na:

  • Kód chyby 701 s chybovou zprávou "Pro spuštění tohoto dotazu není dostatek systémové paměti ve fondu zdrojů %ls".
  • Kód chyby 802 s chybovou zprávou :V fondu vyrovnávací paměti není k dispozici dostatek paměti.

Zobrazení událostí nedostatku paměti

Pokud se objeví chyby kvůli nedostatku paměti, zkontrolujte sys.dm_os_out_of_memory_events. Toto zobrazení obsahuje informace o predikované příčině nedostatku paměti určené heuristickým algoritmem a poskytuje konečný stupeň spolehlivosti.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Prozkoumejte přidělení paměti

Pokud chyby nedostatku paměti přetrvávají v Azure SQL Database, zvažte alespoň dočasné zvýšení cíle na úrovni služby databáze na portálu Azure.

Pokud chyby nedostatku paměti přetrvávají, pomocí následujících dotazů vyhledejte neobvykle vysoké nároky na paměť dotazů, které by mohly přispět k nedostatečnému stavu paměti. Spusťte následující ukázkové dotazy v databázi, u kterých došlo k chybě (ne v databázi master logického serveru Azure SQL).

Použijte DMV k zobrazení událostí nedostatku paměti

sys.dm_os_out_of_memory_events umožňuje viditelnost událostí a příčin událostí nedostatku paměti (OOM) v Azure SQL Database. Rozšířená summarized_oom_snapshot událost je součástí existující system_health relace událostí, která zjednodušuje detekci. Další informace najdete v tématu sys.dm_os_out_of_memory_events a blog: Nový způsob řešení chyb nedostatku paměti v databázovém stroji.

Použijte DMV k zobrazení správců paměti

Začněte rozsáhlým šetřením tím, že pokud k chybě nedostatku paměti došlo nedávno, zkontrolujete přidělení paměti správci paměti. Paměťové registry jsou součástí databázového stroje v Azure SQL Database. Nejvýznamnější paměťoví správci z hlediska přidělených stránek mohou poskytnout informace o tom, jaký typ dotazu nebo funkce SQL Serveru využívá nejvíce paměti.

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;
  • Některé běžné alokátory paměti, jako MEMORYCLERK_SQLQERESERVATIONS, se nejlépe řeší identifikací dotazů s velkými přiděleními paměti a zlepšením jejich výkonu pomocí efektivnějšího indexování a ladění indexů.
  • I když OBJECTSTORE_LOCK_MANAGER nesouvisí s přidělením paměti, je očekáváno, že bude vysoká, když dotazy vyžadují mnoho zámků, například kvůli zakázané eskalaci zámku nebo velmi velkým transakcím.
  • U některých úředníků se očekává nejvyšší využití: MEMORYCLERK_SQLBUFFERPOOL je téměř vždy nejvyšší úředník, zatímco CACHESTORE_COLUMNSTOREOBJECTPOOL bude při použití indexů columnstore vysoké. Očekává se nejvyšší využití těchto úředníků.

Další informace o typech pracovníka paměti najdete v tématu sys.dm_os_memory_clerks.

Použijte zobrazení dynamické správy (DMVs) k prozkoumání aktivních dotazů

Ve většině případů není příčinou této chyby dotaz, který selhal.

Následující ukázkový dotaz pro Azure SQL Database vrátí důležité informace o transakcích, které aktuálně uchovávají nebo čekají na udělení paměti. Zaměřte se na nejčastější dotazy určené pro zkoumání a ladění výkonu a vyhodnoťte, jestli se provádějí podle očekávání. Zvažte načasování dotazů vytvářejících zprávy náročné na paměť nebo operací údržby.

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

Můžete se rozhodnout použít příkaz KILL ke zastavení aktuálně prováděného dotazu, který drží nebo čeká na přidělení velké paměti. Tento příkaz používejte pečlivě, zejména pokud jsou spuštěny důležité procesy. Další informace najdete v tématu KILL (Transact-SQL).

Použití Query Store k prozkoumání využití paměti minulých dotazů

Zatímco předchozí ukázkový dotaz hlásí pouze výsledky živého dotazu, následující dotaz používá Query Store k vrácení informací o minulém spuštění dotazu. To může být užitečné při zkoumání chyby nedostatku paměti, ke které došlo v minulosti.

Následující ukázkový dotaz pro Azure SQL Database vrátí důležité informace o provádění dotazů zaznamenaných Query Store. Zaměřte se na nejčastější dotazy určené pro zkoumání a ladění výkonu a vyhodnoťte, jestli se provádějí podle očekávání. Všimněte si časového filtru qsp.last_execution_time , abyste omezili výsledky na poslední historii. Klauzuli TOP můžete upravit tak, aby v závislosti na vašem prostředí vytvářela více nebo méně výsledků.

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;

Rozšířené události

Kromě předchozích informací může být užitečné zachytit trasování aktivit na serveru a důkladně prozkoumat problém s nedostatkem paměti v Azure SQL Database.

Trasování v SQL Server lze zachytit dvěma způsoby; Rozšířené události (XEvents) a trasování profileru SQL Server Profiler je však zastaralá technologie trasování, která není podporována pro Azure SQL Database. Obslužné události je novější technologie trasování, která umožňuje všestrannější a menší dopad na pozorovaný systém a jeho rozhraní je integrováno do SQL Server Management Studio (SSMS). Další informace o dotazování rozšířených událostí v Azure SQL Database najdete v tématu Obslužné události v Azure SQL Database.

Přečtěte si dokument, který vysvětluje, jak používat Průvodce vytvořením nové relace rozšířených událostí v prostředí SSMS. Pro Azure SQL databáze však SSMS poskytuje podsložku Rozšířených událostí v každé databázi v Object Explorer. Pomocí relace rozšířených událostí zachyťte tyto užitečné události a identifikujte dotazy, které je generují:

  • Chyby kategorií:

    • error_reported
    • exchange_spill
    • hash_spill_details

  • Provádění kategorií:

    • excessive_non_grant_memory_used

  • Paměť kategorií:

    • query_memory_grant_blocking
    • query_memory_grant_usage

  • summarized_oom_snapshot

    Zachycení bloků přidělení paměti, přetečení paměti nebo nadměrného přidělení paměti může být potenciálním vodítkem pro dotaz, který náhle přebírá více paměti než v minulosti, a potenciálním vysvětlením nově vznikající chyby nedostatku paměti v existující úloze. Rozšířená summarized_oom_snapshot událost je součástí existující system_health relace událostí, která zjednodušuje detekci. Další informace najdete v tématu Blog: Nový způsob řešení chyb nedostatku paměti v databázovém stroji.

Nedostatek paměti OLTP v paměti

Můžete narazit na Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation, pokud používáte In-Memory OLTP. Snižte množství dat v tabulkách optimalizovaných pro paměť a parametrech optimalizovaných pro paměť nebo vertikálně navyšte kapacitu databáze na vyšší cíl služby, aby měla více paměti. Další informace o problémech s nedostatkem paměti SQL Server In-Memory OLTP najdete v tématu Problémy s nedostatkem paměti.

Získání podpory Azure SQL Database

Pokud v Azure SQL Database přetrvávají chyby nedostatku paměti, vytvořte požadavek na podporu Azure tak, že na webu Azure Support vyberete Get Support.

Související obsah

  • Last updated on