Share via

Řešení chyb nedostatku paměti ve službě Azure SQL Database

  • Článek

Platí pro:Azure SQL Database

Můžou se zobrazit chybové zprávy, když databázový stroj SQL nepodařilo 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 prostředků ve službě Azure SQL Database.

Poznámka:

Tento článek se zaměřuje na Azure SQL Database. Další informace o řešení potíží s nedostatkem paměti v SQL Serveru 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 dojde k chybám s nedostatkem 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;

Prozkoumání přidělení paměti

Pokud chyby nedostatku paměti přetrvávají ve službě Azure SQL Database, zvažte alespoň dočasné zvýšení cíle na úrovni služby databáze na webu Azure Portal. 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 master databázi logického serveru Azure SQL).

Zobrazení událostí nedostatku paměti pomocí zobrazení dynamické správy

Umožňuje sys.dm_os_out_of_memory_events viditelnost událostí a příčin událostí nedostatku paměti (OOM) ve službě 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.

Zobrazení úředníků paměti pomocí zobrazení dynamické správy

Začněte rozsáhlým šetřením, pokud k chybě nedostatku paměti došlo nedávno, zobrazením přidělení paměti pro pracovníky paměti. Pracovníci paměti jsou interní pro databázový stroj pro tuto službu Azure SQL Database. Nejvyšší správci paměti z hlediska přidělených stránek můžou mít 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é pracovníky paměti, jako je například MEMORYCLERK_SQLQERESERVATIONS, jsou nejlépe vyřešeny identifikací dotazů s velkými přiděleními paměti a zlepšením jejich výkonu s lepším indexováním a laděním indexů.
  • I když OBJECTSTORE_LOCK_MANAGER nesouvisí s přidělením paměti, očekává se, že je vysoká, když dotazy deklarují mnoho zámků, například kvůli eskalaci zakázaného zámku nebo velmi velkých transakcí.
  • 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.

Zkoumání aktivních dotazů pomocí zobrazení dynamické správy

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ů na generování sestav náročných 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 k zastavení aktuálně spuštěného dotazu, který se drží nebo čeká na udělení velké paměti. Tento příkaz používejte pečlivě, zejména pokud jsou spuštěny důležité procesy. Další informace naleznete v tématu KILL (Transact-SQL).

Použití úložiště dotazů 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á úložiště dotazů 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 vrací důležité informace o spouštění dotazů zaznamenaných úložištěm dotazů. 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 ve službě Azure SQL Database.

Trasování v SQL Serveru lze zachytit dvěma způsoby; Rozšířené události (XEvents) a trasování profileru Sql Server Profiler je však zastaralá trasovací technologie, která není pro Azure SQL Database podporovaná. Extended Events je novější technologie trasování, která umožňuje všestrannější a menší dopad na pozorovaný systém a jeho rozhraní je integrované do aplikace SQL Server Management Studio (SSMS). Další informace o dotazování rozšířených událostí ve službě Azure SQL Database najdete v tématu Rozšířené události ve službě 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 nástroji SSMS. Pro databáze Azure SQL však SSMS poskytuje podsložku Rozšířených událostí v každé databázi v Průzkumník objektů. 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řelití 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í vysvětlení 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

Pokud používáte OLTP v paměti, můžete narazit Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation . 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 u OLTP v paměti SQL Serveru najdete v tématu Řešení problémů s nedostatkem paměti.

Získání podpory služby Azure SQL Database

Pokud chyby nedostatku paměti přetrvávají ve službě Azure SQL Database, vytvořte žádost podpora Azure výběrem možnosti Získat podporu na webu podpory Azure.

Související obsah