Azure SQL Veritabanı ile ilgili yetersiz bellek sorunlarını giderme

  • Makale

Şunlar için geçerlidir:Azure SQL Veritabanı

SQL veritabanı altyapısı sorguyu çalıştırmak için yeterli bellek ayıramadığında hata iletileri görebilirsiniz. Bu hatalar seçilen hizmet hedefinin sınırları, toplu iş yükü bellek talepleri ve sorgu bellek talepleri gibi birçok farklı nedenden kaynaklanabilir. Azure SQL Veritabanı bellek kaynağı sınırı hakkında daha fazla bilgi için bkz. Azure SQL Veritabanı kaynak yönetimi.

Not

Bu makale Azure SQL Veritabanı odaklanmıştır. SQL Server'da yetersiz bellek sorunlarını giderme hakkında daha fazla bilgi için bkz . MSSQLSERVER_701.

Yanıt olarak aşağıdaki araştırma yollarını deneyin:

  • "'%ls' kaynak havuzunda bu sorguyu çalıştırmak için yetersiz sistem belleği var" hata iletisiyle 701 hata kodu.
  • Hata kodu 802 "Arabellek havuzunda kullanılabilir bellek yetersiz." hata iletisiyle birlikte.

Bellek dışı olayları görüntüleme

Yetersiz bellek hatalarıyla karşılaşırsanız sys.dm_os_out_of_memory_events içeriğini gözden geçirin. Bu görünüm, buluşsal bir algoritma tarafından belirlenen ve sonlu bir güvenilirlik derecesiyle sağlanan, tahmin edilen yetersiz bellek nedeni hakkında bilgi içerir.

SELECT * FROM sys.dm_os_out_of_memory_events ORDER BY event_time DESC;

Bellek ayırmayı araştırma

bellek yetersiz hataları Azure SQL Veritabanı devam ederse, Azure portalında veritabanının hizmet düzeyi hedefini en azından geçici olarak artırmayı göz önünde bulundurun. Yetersiz bellek hataları devam ederse, yetersiz bellek koşuluna katkıda bulunabilecek olağan dışı yüksek sorgu belleği izinlerini aramak için aşağıdaki sorguları kullanın. Hatayla karşılaşan veritabanında (Azure SQL mantıksal sunucusunun veritabanında değil master ) aşağıdaki örnek sorguları çalıştırın.

Yetersiz bellek olaylarını görüntülemek için DMV kullanma

, sys.dm_os_out_of_memory_events Azure SQL Veritabanı bellek yetersizliği (OOM) olaylarının görünürlüğünü ve nedenlerini sağlar. Genişletilmiş summarized_oom_snapshot olay, algılamayı basitleştirmek için mevcut system_health olay oturumunun bir parçasıdır. Daha fazla bilgi için bkz . sys.dm_os_out_of_memory_events ve Blog: Veritabanı altyapısındaki yetersiz bellek hatalarını gidermenin yeni bir yolu.

Bellek katiplerini görüntülemek için DMV'leri kullanma

Bellek yetersiz hatasının yakın zamanda oluşup oluşmadığı konusunda kapsamlı bir araştırmayla başlayın ve bellek ayırmayı bellek katiplerine görüntüleyin. Bellek katipleri bu Azure SQL Veritabanı için veritabanı altyapısının iç birimidir. Ayrılan sayfalar açısından en üstteki bellek katipleri, SQL Server'ın en çok bellek tüketen sorgu veya özellik türü konusunda bilgilendirici olabilir.

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;
  • MEMORYCLERK_SQLQERESERVATIONS gibi bazı yaygın bellek katipleri en iyi şekilde büyük bellek izinleri olan sorguları tanımlayarak ve daha iyi dizin oluşturma ve dizin ayarlama ile performanslarını geliştirerek çözümlenir.
  • OBJECTSTORE_LOCK_MANAGER bellek atamalarıyla ilgisi olmasa da, sorgular çok sayıda kilit talep ettiğinde( örneğin devre dışı bırakılmış kilit yükseltmesi veya çok büyük işlemler nedeniyle) yüksek olması beklenir.
  • Bazı katiplerin en yüksek kullanımda olması beklenir: MEMORYCLERK_SQLBUFFERPOOL neredeyse her zaman en üst katip olurken, columnstore dizinleri kullanıldığında CACHESTORE_COLUMNSTOREOBJECTPOOL yüksek olacaktır. Bu memurların en yüksek kullanımı bekleniyor.

Bellek katibi türleri hakkında daha fazla bilgi için bkz . sys.dm_os_memory_clerks.

Etkin sorguları araştırmak için DMV'leri kullanma

Çoğu durumda, başarısız olan sorgu bu hatanın nedeni değildir.

Azure SQL Veritabanı için aşağıdaki örnek sorgu, şu anda bellek atamalarını tutan veya bekleyen işlemler hakkında önemli bilgiler döndürür. İnceleme ve performans ayarlaması için tanımlanan en önemli sorguları hedefleyin ve istendiği gibi yürütülüyor olup olmadığını değerlendirin. Yoğun bellek kullanan raporlama sorgularının veya bakım işlemlerinin zamanlamasını göz önünde bulundurun.

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

Büyük bir bellek iznini tutan veya bekleyen şu anda yürütülen bir sorguyu durdurmak için KILL deyimini kullanmaya karar vekleyebilirsiniz. Özellikle kritik işlemler çalışırken bu deyimi dikkatle kullanın. Daha fazla bilgi için bkz . KILL (Transact-SQL).

Geçmiş sorgu belleği kullanımını araştırmak için Sorgu Deposu'yu kullanma

Önceki örnek sorgu yalnızca canlı sorgu sonuçlarını raporlasa da, aşağıdaki sorgu geçmiş sorgu yürütme hakkında bilgi döndürmek için Sorgu Deposu'nı kullanır. Bu, geçmişte oluşan bellek yetersiz hatasının araştırılmasında yararlı olabilir.

Azure SQL Veritabanı için aşağıdaki örnek sorgu, Sorgu Deposu tarafından kaydedilen sorgu yürütmeleriyle ilgili önemli bilgileri döndürür. İnceleme ve performans ayarlaması için tanımlanan en önemli sorguları hedefleyin ve istendiği gibi yürütülüyor olup olmadığını değerlendirin. Sonuçları yakın geçmişle sınırlamak için zaman filtresinin açık qsp.last_execution_time olduğunu unutmayın. TOP yan tümcesini ortamınıza bağlı olarak daha fazla veya daha az sonuç üretecek şekilde ayarlayabilirsiniz.

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;

Genişletilmiş olaylar

Önceki bilgilere ek olarak, Azure SQL Veritabanı bellek yetersiz sorununu kapsamlı bir şekilde araştırmak için sunucudaki etkinliklerin bir izlemesini yakalamak yararlı olabilir.

SQL Server'da izlemeleri yakalamanın iki yolu vardır; Genişletilmiş Olaylar (XEvents) ve Profil Oluşturucu İzlemeleri. Ancak SQL Server Profiler, Azure SQL Veritabanı için desteklenmeyen kullanım dışı izleme teknolojisidir. Genişletilmiş Olaylar , gözlemlenen sisteme daha çok yönlülük ve daha az etki sağlayan daha yeni izleme teknolojisidir ve arabirimi SQL Server Management Studio (SSMS) ile tümleşiktir. Azure SQL Veritabanı'da genişletilmiş olayları sorgulama hakkında daha fazla bilgi için bkz. Azure SQL Veritabanı genişletilmiş olaylar.

SSMS'de Genişletilmiş Olaylar Yeni Oturum Sihirbazı'nın nasıl kullanılacağını açıklayan belgeye bakın. Ancak Azure SQL veritabanları için SSMS, Nesne Gezgini'deki her veritabanının altında bir Genişletilmiş Olaylar alt klasörü sağlar. Bu yararlı olayları yakalamak ve bunları oluşturan sorguları belirlemek için Genişletilmiş Olaylar oturumu kullanın:

  • Kategori Hataları:

    • error_reported
    • exchange_spill
    • hash_spill_details

  • Kategori Yürütme:

    • excessive_non_grant_memory_used

  • Kategori Belleği:

    • query_memory_grant_blocking
    • query_memory_grant_usage

  • summarized_oom_snapshot

    Bellek verme bloklarının, bellek atama taşmalarının veya aşırı bellek atamalarının yakalanması, sorgunun geçmişteki bellekten daha fazla bellek almasına ve mevcut bir iş yükünde ortaya çıkan bellek yetersiz hatasının olası açıklamasına yönelik olası bir ipucu olabilir. Genişletilmiş summarized_oom_snapshot olay, algılamayı basitleştirmek için mevcut system_health olay oturumunun bir parçasıdır. Daha fazla bilgi için bkz . Blog: Veritabanı altyapısındaki yetersiz bellek hatalarını gidermenin yeni bir yolu.

Bellek içi OLTP yetersiz bellek

Bellek İçi OLTP kullanıyorsanız karşılaşabilirsiniz Error code 41805: There is insufficient memory in the resource pool '%ls' to run this operation . Bellek için iyileştirilmiş tablolardaki ve bellek için iyileştirilmiş tablo değerli parametrelerdeki veri miktarını azaltın veya daha fazla belleğe sahip olmak için veritabanını daha yüksek bir hizmet hedefine ölçeklendirin. SQL Server Bellek İçi OLTP ile ilgili yetersiz bellek sorunları hakkında daha fazla bilgi için bkz . Yetersiz Bellek sorunlarını çözme.

Azure SQL Veritabanı desteği alın

Bellek yetersiz hataları Azure SQL Veritabanı devam ederse Azure Destek sitesinde Destek Al'ı seçerek bir Azure desteği isteği oluşturun.

İlgili içerik