Rozwiązywanie problemów z błędami braku pamięci za pomocą bazy danych Azure SQL Database

  • Artykuł

Dotyczy:Azure SQL Database

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 baz danych Azure SQL Database, zobacz Zarządzanie zasobami w usłudze Azure SQL Database.

Uwaga

Ten artykuł koncentruje się na usłudze Azure SQL Database. Aby uzyskać więcej informacji na temat rozwiązywania problemów z brakiem pamięci w programie 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 pamięci dostępnej 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 usłudze Azure SQL Database, rozważ przynajmniej tymczasowe zwiększenie celu poziomu usługi bazy danych w witrynie Azure Portal. 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 zapytań, które mogą przyczynić się do niewystarczającego stanu pamięci. Uruchom następujące przykładowe zapytania w bazie danych, które napotkały błąd (nie w master bazie danych serwera logicznego Azure SQL).

Wyświetlanie zdarzeń braku pamięci za pomocą dynamicznego widoku zarządzania

Funkcja sys.dm_os_out_of_memory_events umożliwia widoczność zdarzeń i przyczyn braku pamięci (OOM) w usłudze 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 braku pamięci w a aparatu bazy danych.

Wyświetlanie buforów pamięci za pomocą widoków DMV

Zacznij od szerokiego badania, jeśli ostatnio wystąpił błąd braku pamięci, wyświetlając alokację pamięci do urzędników pamięci. Bufory pamięci są wewnętrzne dla aparatu bazy danych dla tej usługi Azure SQL Database. Najważniejsze bufory pamięci pod względem przydzielonych stron mogą być informacyjne dla typu zapytania lub funkcji programu 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 udzielaniem pamięci, oczekuje się, że jest wysokie, gdy zapytania zgłaszają wiele blokad, na przykład z powodu wyłączonej eskalacji blokady lub bardzo dużych transakcji.
  • Oczekuje się, że niektórzy urzędnicy będą najwyższym wykorzystaniem: MEMORYCLERK_SQLBUFFERPOOL jest prawie zawsze najwyższym urzędnikem, podczas gdy CACHESTORE_COLUMNSTOREOBJECTPOOL będą wysokie, gdy są używane indeksy magazynu kolumn. Oczekuje się najwyższego wykorzystania przez tych urzędników.

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

Używanie widoków 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 usługi Azure SQL Database zwraca ważne informacje dotyczące transakcji, które są obecnie w posiadaniu lub oczekujących na dotacje na pamięć. 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 jest wstrzymujące lub oczekujące 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).

Korzystanie z magazynu zapytań w celu zbadania wcześniejszego użycia pamięci zapytań

Chociaż poprzednie przykładowe zapytanie raportuje tylko wyniki zapytań na żywo, następujące zapytanie używa magazynu zapytań do zwracania informacji dotyczących poprzedniego wykonywania zapytania. Może to być przydatne podczas badania błędu braku pamięci, który wystąpił w przeszłości.

Poniższe przykładowe zapytanie dla usługi Azure SQL Database zwraca ważne informacje dotyczące wykonań zapytań zarejestrowanych przez magazyn zapytań. 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 usłudze Azure SQL Database.

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

Zapoznaj się z dokumentem, w ramach którego wyjaśniono, jak używać Kreatora nowych sesji zdarzeń rozszerzonych w programie SSMS. Jednak w przypadku baz danych Azure SQL Database program SSMS udostępnia podfolder zdarzeń rozszerzonych w każdej bazie danych w Eksplorator obiektów. 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

  • Wykonywanie 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, rozlanie przydziału pamięci lub nadmierne przydziały pamięci może być potencjalną wskazówką dla zapytania, które nagle zajęło więcej pamięci niż w przeszłości, oraz potencjalne wyjaśnienie wystąpienia błędu 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 a aparatze bazy danych.

Brak pamięci olTP w pamięci

W przypadku korzystania 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 błąd OLTP. 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 z funkcją OLTP programu SQL Server w pamięci, zobacz Rozwiązywanie problemów z brakiem pamięci.

Uzyskiwanie pomocy technicznej usługi Azure SQL Database

Jeśli błędy braku pamięci będą nadal występować w usłudze Azure SQL Database, prześlij żądanie pomoc techniczna platformy Azure, wybierając pozycję Uzyskaj pomoc techniczną w witrynie pomocy technicznej platformy Azure.

Powiązana zawartość