Az Azure SQL Database és a Fabric SQL Database memóriakimerülési hibáinak elhárítása

A következőkre vonatkozik:Azure SQL Database SQL Database a Fabricben

Hibaüzenetek jelenhetnek meg, ha az SQL-adatbázismotor nem tudott elegendő memóriát lefoglalni a lekérdezés futtatásához. Ezt különböző okok okozhatják, beleértve a kiválasztott szolgáltatáscél korlátait, a számítási feladatok összesített memóriaigényét és a lekérdezés memóriaigényét.

Az Azure SQL Database memóriaerőforrás-korlátját az Azure SQL Database erőforrás-kezelésével foglalkozó cikkben talál. A Fabric SQL Database számos funkciót oszt meg az Azure SQL Database-zel. A teljesítménymonitorozásról további információt a Fabric SQL-adatbázis teljesítménymonitorozásával kapcsolatban talál.

Az SQL Server memóriakihasználtságával kapcsolatos problémák elhárításáról további információt a MSSQLSERVER_701 című témakörben talál.

Próbálja ki a következő vizsgálati lehetőségeket a következőkre válaszul:

"Nincs elegendő rendszermemória a%ls" erőforráskészletben a lekérdezés futtatásához" hibaüzenettel ellátott 701-s hibakód.
"Nincs elegendő memória a pufferkészletben" hibaüzenettel ellátott 802-s hibakód.

Memóriaen kívüli események megtekintése

Ha memóriahiba lépett fel, tekintse át sys.dm_os_out_of_memory_events. Ez a nézet információkat tartalmaz a memóriahiány előrejelzett okáról, amelyet heurisztikus algoritmus határoz meg, és véges megbízhatósági szinttel rendelkezik.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Memóriafoglalás vizsgálata

Ha az Azure SQL Database-ben memóriahiba áll fenn, fontolja meg legalább az adatbázis szolgáltatásiszint-célkitűzésének ideiglenes növelését az Azure Portalon.

Ha a memóriahiány továbbra is fennáll, az alábbi lekérdezésekkel szokatlanul magas lekérdezési memóriakihasználtságokat kereshet, amelyek hozzájárulhatnak a memória elégtelen állapotához. Futtassa a következő példa lekérdezéseket az adatbázisban, amely a hibát észlelte (nem az master Azure SQL logikai kiszolgáló adatbázisában).

Memóriaen kívüli események megtekintése a DMV használatával

Ez sys.dm_os_out_of_memory_events lehetővé teszi az Azure SQL Database-ben a memóriakihasználtság (OOM) eseményeinek és okainak láthatóságát. A summarized_oom_snapshot kiterjesztett esemény a meglévő system_health esemény munkamenet része az észlelés egyszerűsítése érdekében. További információ: sys.dm_os_out_of_memory_events és blog: Új módszer a memóriakihasználtság hibáinak elhárítására az adatbázismotorban.

Memóriajegyzők megtekintése DMV-k használatával

Kezdje egy széles körű vizsgálattal, ha a memóriakifogyási hiba nemrégiben történt, a memória írnokoknak juttatott memória elosztásának megtekintésével. A memóriajegyzők az Azure SQL Database adatbázismotorjának belső elemei. A lefoglalt lapok tekintetében a legfontosabb memóriajegyzők informatívak lehetnek arról, hogy az SQL Server milyen típusú lekérdezést vagy funkciót használ fel a legtöbb memóriát.

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;

Egyes gyakori memóriajegyzők, például a MEMORYCLERK_SQLQERESERVATIONS a legjobban úgy oldhatók meg, hogy azonosítják a nagy memóriahasználattal rendelkező lekérdezéseket, és jobb indexeléssel és indexhangolással javítják a teljesítményüket.
Bár OBJECTSTORE_LOCK_MANAGER nem kapcsolódik a memóriaengedélyhez, várhatóan magas értéket mutat, ha a lekérdezés során számos zárolást használnak, például zárolás eszkalációjának letiltása vagy nagyon nagy tranzakciók miatt.
Néhány memória kezelő várhatóan a legmagasabb kihasználtságú lesz: a MEMORYCLERK_SQLBUFFERPOOL szinte mindig a legnagyobb kihasználtságot éri el, míg a CACHESTORE_COLUMNSTOREOBJECTPOOL magas lesz, amikor oszlop tároló indexeket használnak. A legnagyobb kihasználtság ezektől a hivatalnokoktól várható.

További információ a memóriajegyzők típusairól: sys.dm_os_memory_clerks.

Aktív lekérdezések vizsgálatához a DMV-k használata

A legtöbb esetben nem a sikertelen lekérdezés okozza ezt a hibát.

Az Azure SQL Database következő minta lekérdezése fontos információkat ad vissza azokról a tranzakciókról, amelyek jelenleg memóriakijuttatásokat tartanak vagy várnak. Megcélozza a vizsgálathoz és a teljesítmény finomhangolásához azonosított legfontosabb lekérdezéseket, és értékelje ki, hogy a lekérdezések a kívánt módon hajtják-e végre őket. Fontolja meg a memóriaigényes jelentéskészítő lekérdezések vagy karbantartási műveletek időzítését.

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

Dönthet úgy, hogy a KILL utasítással leállít egy jelenleg futó lekérdezést, amely nagy memória-hozzáférést tart vagy várakozik rá. Ezt az utasítást körültekintően használja, különösen kritikus folyamatok futtatásakor. További információ: KILL (Transact-SQL).

A Lekérdezéstár használata a korábbi lekérdezési memóriahasználat vizsgálatához

Míg az előző minta lekérdezés csak élő lekérdezési eredményeket jelent, a következő lekérdezés a Lekérdezéstár használatával ad vissza adatokat a korábbi lekérdezések végrehajtásáról. Ez hasznos lehet egy múltban bekövetkezett memóriahiányos hiba vizsgálatában.

Az Azure SQL Database következő minta lekérdezése fontos információkat ad vissza a lekérdezéstár által rögzített lekérdezés-végrehajtásokról. Megcélozza a vizsgálathoz és a teljesítmény finomhangolásához azonosított legfontosabb lekérdezéseket, és értékelje ki, hogy a lekérdezések a kívánt módon hajtják-e végre őket. Figyelje meg az időszűrőt, qsp.last_execution_time hogy az eredményeket a legutóbbi előzményekre korlátozza. A TOP záradékot úgy módosíthatja, hogy a környezetétől függően több vagy kevesebb eredményt hozzon létre.

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;

Bővített események

Az előző információkon kívül hasznos lehet a kiszolgálón végzett tevékenységek nyomának rögzítése, hogy alaposan kivizsgálhassa az Azure SQL Database-ben a memóriakihasználtsággal kapcsolatos problémákat.

A nyomkövetések kétféleképpen rögzíthetők az SQL Serveren; Bővített események (XEvents) és Profiler-nyomkövetések. Az SQL Server Profiler azonban elavult nyomkövetési technológia, amely nem támogatott az Azure SQL Database-ben. A Kiterjesztett események az újabb nyomkövetési technológia, amely sokoldalúbb és kevésbé befolyásolja a megfigyelt rendszert, és a felülete integrálva van az SQL Server Management Studióba (SSMS). A kiterjesztett események Azure SQL Database-ben való lekérdezéséről további információt az Azure SQL Database kiterjesztett eseményei című témakörben talál.

Tekintse meg azt a dokumentumot, amely bemutatja, hogyan használható a Bővített események új munkamenet varázslója az SSMS-ben. Az Azure SQL-adatbázisok esetében azonban az SSMS egy Kiterjesztett események almappát biztosít az Object Explorerben lévő adatbázisok alatt. A bővített események munkamenetével rögzítheti ezeket a hasznos eseményeket, és azonosíthatja az őket generáló lekérdezéseket:

Kategóriahibák:
- error_reported
- exchange_spill
- hash_spill_details
Végrehajtás kategória szerint:
- excessive_non_grant_memory_used
Memóriakategória
- query_memory_grant_blocking
- query_memory_grant_usage
summarized_oom_snapshot

A memóriaengedélyezési blokkok, a memóriaengedélyezési kiömlések vagy a túlzott memóriaengedélyek rögzítése lehetséges nyom lehet egy olyan lekérdezésben, amely hirtelen több memóriát vesz igénybe, mint korábban, és lehetséges magyarázat lehet egy meglévő munkafolyamatban fellépő újabb memóriakimaradásos hiba esetén. A summarized_oom_snapshot kiterjesztett esemény a meglévő system_health esemény munkamenet része az észlelés egyszerűsítése érdekében. További információ : Blog: A memóriakihasználtság hibáinak elhárításának új módja az adatbázismotorban.

Memóriabeli OLTP memóriahiány

Előfordulhat, ha In-Memory OLTP-t használ, Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation. Csökkentse a memóriaoptimalizált táblákban és a memóriaoptimalizált táblaértékekkel rendelkező paraméterekben lévő adatok mennyiségét, vagy skálázza fel az adatbázist egy magasabb szolgáltatási célkitűzésre, hogy több memóriával rendelkezzen. Az SQL Server In-Memory OLTP memóriakihasználtságával kapcsolatos problémákról további információt a memóriakihasználtság problémáinak megoldása című témakörben talál.

Az Azure SQL Database támogatásának lekérése

Ha nem áll fenn memóriahiba az Azure SQL Database-ben, küldjön egy Azure-támogatási kérést az Azure támogatási webhelyén a Támogatás kérése lehetőség kiválasztásával.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-20