Udostępnij za pośrednictwem

Rozwiązywanie problemów z błędami braku pamięci w bazie danych Azure SQL Database i Fabric SQL Database

Applies to:Azure SQL DatabaseSQL database in Fabric

Mogą pojawić się komunikaty o błędach, gdy aparat bazy danych SQL nie może przydzielić wystarczającej ilości pamięci do uruchomienia zapytania. Może to być spowodowane różnymi przyczynami, takimi jak limity wybranego celu usługi, zapotrzebowanie na pamięć zagregowanych obciążeń oraz zapotrzebowanie na pamięć zapytania.

Aby uzyskać więcej informacji na temat limitu zasobów pamięci dla Azure SQL Database, zobacz Zarządzanie zasobami w Azure SQL Database. Usługa Fabric SQL Database udostępnia wiele funkcji Azure SQL Database, aby uzyskać więcej informacji na temat monitorowania wydajności, zobacz Monitorowanie wydajności bazy danych SQLAbric.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z brakiem pamięci w SQL Server, zobacz MSSQLSERVER_701.

Spróbuj wykonać następujące kroki badania w odpowiedzi na:

  • Kod błędu 701 z komunikatem o błędzie "Brak pamięci systemowej w puli zasobów %ls" do uruchomienia tego zapytania.
  • Kod błędu 802 z komunikatem o błędzie "Brak wystarczającej ilości pamięci w puli buforów".

Wyświetlanie zdarzeń braku pamięci

Jeśli wystąpią błędy dotyczące braku pamięci, przejrzyj widok sys.dm_os_out_of_memory_events. Ten widok zawiera informacje na temat przewidywanej przyczyny braku pamięci, określonych przez algorytm heurystyczny i jest dostarczany ze skończonym stopniem ufności.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Badanie alokacji pamięci

Jeśli błędy braku pamięci będą nadal występować w Azure SQL Database, rozważ przynajmniej tymczasowe zwiększenie celu poziomu usługi bazy danych w portalu Azure.

Jeśli błędy braku pamięci będą nadal występować, użyj następujących zapytań, aby wyszukać niezwykle wysokie przydziały pamięci dla zapytań, które mogą przyczynić się do stanu niewystarczającej pamięci. Uruchom następujące przykładowe zapytania w bazie danych, które napotkały błąd (nie w bazie danych master serwera logicznego Azure SQL).

Użyj DMV, aby wyświetlić zdarzenia braku pamięci.

sys.dm_os_out_of_memory_events umożliwia monitorowanie zdarzeń oraz przyczyn braku pamięci (OOM) w Azure SQL Database. Zdarzenie summarized_oom_snapshot rozszerzone jest częścią istniejącej system_health sesji zdarzeń, aby uprościć wykrywanie. Aby uzyskać więcej informacji, zobacz sys.dm_os_out_of_memory_events i Blog: „nowy sposób rozwiązywania problemów z błędami związanymi z brakiem pamięci w aparacie bazy danych”.

Użyj widoków zarządzania dynamicznego (DMV) do przeglądania urzędników pamięci.

Rozpocznij od szerokiego badania, jeśli ostatnio wystąpił błąd braku pamięci, sprawdzając alokację pamięci przez zarządców pamięci. Rejestratory pamięci są integralną częścią aparatu bazodanowego tego Azure SQL Database. Zarządcy pamięci pod względem przydzielonych stron mogą dostarczać informacji o tym, jaki typ zapytania lub funkcja SQL Server zużywa najwięcej pamięci.

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;
  • Niektóre typowe urzędy obsługi pamięci, takie jak MEMORYCLERK_SQLQERESERVATIONS, najlepiej rozwiązać, identyfikując zapytania z dużymi przydziałami pamięci i poprawiając ich wydajność dzięki lepszym indeksowaniu i dostrajaniu indeksów.
  • Chociaż OBJECTSTORE_LOCK_MANAGER nie ma związku z przydziałami pamięci, oczekuje się, że jego wartość będzie wysoka, gdy zapytania powodują wiele blokad, na przykład ze względu na wyłączoną eskalację blokad lub bardzo duże transakcje.
  • Oczekuje się, że niektóre bufory pamięci będą mieć największe wykorzystanie zasobów: MEMORYCLERK_SQLBUFFERPOOL jest prawie zawsze najbardziej wykorzystywanym, podczas gdy CACHESTORE_COLUMNSTOREOBJECTPOOL osiągnie wysoką wartość, gdy używane są indeksy columnstore. Oczekuje się, że ci pracownicy biurowi będą wykorzystywani na najwyższym poziomie.

Aby uzyskać więcej informacji na temat typów urzędników pamięci, zobacz sys.dm_os_memory_clerks.

Użyj dynamicznych widoków zarządzanych (DMV) do badania aktywnych zapytań

W większości przypadków zapytanie, które zakończyło się niepowodzeniem, nie jest przyczyną tego błędu.

Poniższe przykładowe zapytanie dla bazy danych Azure SQL zwraca ważne informacje o transakcjach, które obecnie posiadają lub oczekują na przyznanie zasobów pamięci. Określ najważniejsze zapytania zidentyfikowane na potrzeby badania i dostrajania wydajności oraz oceń, czy są wykonywane zgodnie z oczekiwaniami. Rozważ czas wykonywania zapytań raportowania intensywnie korzystających z pamięci lub operacji konserwacji.

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

Możesz użyć instrukcji KILL, aby zatrzymać aktualnie wykonywane zapytanie, które trzyma lub oczekuje na przyznanie dużej ilości pamięci. Użyj tej instrukcji ostrożnie, szczególnie w przypadku uruchamiania procesów krytycznych. Aby uzyskać więcej informacji, zobacz KILL (Transact-SQL).

Użyj Query Store do badania użycia pamięci zapytań w przeszłości

Chociaż poprzednie przykładowe zapytanie zgłasza tylko wyniki zapytania na żywo, następujące zapytanie używa Query Store aby zwrócić informacje dotyczące wcześniejszego wykonania zapytania. Może to być przydatne podczas badania błędu braku pamięci, który wystąpił w przeszłości.

Następujące przykładowe zapytanie dotyczące Azure SQL Database zwraca ważne informacje dotyczące wykonań zapytań zarejestrowanych przez Query Store. Określ najważniejsze zapytania zidentyfikowane na potrzeby badania i dostrajania wydajności oraz oceń, czy są wykonywane zgodnie z oczekiwaniami. Zanotuj filtr czasu, qsp.last_execution_time aby ograniczyć wyniki do najnowszej historii. Możesz dostosować klauzulę TOP, aby wygenerować więcej lub mniej wyników w zależności od środowiska.

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;

Zdarzenia rozszerzone

Oprócz poprzednich informacji pomocne może być przechwycenie śladu działań na serwerze w celu dokładnego zbadania problemu z brakiem pamięci w Azure SQL Database.

Istnieją dwa sposoby przechwytywania śladów w SQL Server: Zdarzenia rozszerzone (XEvents) i ślady profilowania. Jednak technologia śledzenia SQL Server Profiler jest przestarzała i nie jest obsługiwana w przypadku Azure SQL Database. Extended Events to nowsza technologia śledzenia, która umożliwia bardziej wszechstronność i mniejszy wpływ na obserwowany system, a jego interfejs jest zintegrowany z SQL Server Management Studio (SSMS). Aby uzyskać więcej informacji na temat wykonywania zapytań dotyczących zdarzeń rozszerzonych w Azure SQL Database, zobacz Extended events w Azure SQL Database.

Zapoznaj się z dokumentem, w ramach którego wyjaśniono, jak używać Kreatora nowych sesji zdarzeń rozszerzonych w programie SSMS. W przypadku baz danych Azure SQL program SSMS udostępnia jednak podfolder zdarzeń rozszerzonych w każdej bazie danych w Object Explorer. Użyj sesji zdarzeń rozszerzonych, aby przechwycić te przydatne zdarzenia i zidentyfikować zapytania generujące je:

  • Błędy kategorii:

    • error_reported
    • exchange_spill
    • hash_spill_details

  • Realizacja kategorii:

    • excessive_non_grant_memory_used

  • Pamięć kategorii:

    • query_memory_grant_blocking
    • query_memory_grant_usage

  • summarized_oom_snapshot

    Przechwytywanie bloków przydziału pamięci, przekroczenie przydziału pamięci lub nadmierne przydziały pamięci mogą być potencjalną wskazówką dla zapytania, które nagle zaczęło używać więcej pamięci niż w przeszłości, a także potencjalnym wyjaśnieniem pojawiającego się błędu braku pamięci w istniejącym obciążeniu. Zdarzenie summarized_oom_snapshot rozszerzone jest częścią istniejącej system_health sesji zdarzeń, aby uprościć wykrywanie. Aby uzyskać więcej informacji, zobacz Blog: Nowy sposób rozwiązywania problemów z błędami braku pamięci w aparacie bazy danych.

Zabrakło pamięci dla OLTP w pamięci

Jeśli korzystasz z funkcji OLTP w pamięci, może wystąpić Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation. Zmniejsz ilość danych w tabelach zoptymalizowanych pod kątem pamięci i zoptymalizowanych pod kątem pamięci parametrów tabel lub przeprowadź skalowanie bazy danych w górę do wyższego celu usługi, aby mieć więcej pamięci. Aby uzyskać więcej informacji na temat problemów z brakiem pamięci w SQL Server In-Memory OLTP, zobacz Resolve Out Of Memory issues ( Problemy z brakiem pamięci).

Wsparcie dla Azure SQL Database

Jeśli błędy braku pamięci będą nadal występować w Azure SQL Database, prześlij żądanie Azure support, wybierając pozycję Pobierz pomoc techniczną w witrynie Azure Support.

Powiązana zawartość

  • Last updated on