MSSQLSERVER_701

Şunlar için geçerlidir: SQL Server

Details

Attribute Value
Ürün Adı SQL Server
Olay Kimliği 701
Olay Kaynağı MSSQLSERVER
Bileşen SQLEngine
Sembolik Ad NOSYSMEM
İleti Metni Bu sorguyu çalıştırmak için yeterli sistem belleği yok.

Note

Bu makale SQL Server'a odaklanmaktadır. Azure SQL Veritabanı'de bellek dışı hataların giderilmesi hakkında bilgi için bkz. Azure SQL Veritabanı ile bellek dışı hataları sorun çözme.

Explanation

701 hatası, SQL Server'ın bir sorgu çalıştırmak için yeterli bellek ayıramadığı durumlarda meydana gelir. Yetersiz bellek ise işletim sistemi ayarları, fiziksel bellek kullanılabilirliği, diğer bileşenlerin SQL Server içindeki bellek kullanması veya mevcut iş yükündeki bellek sınırlamaları gibi birçok faktörden kaynaklanabilir. Çoğu durumda, başarısız olan işlem bu hatanın sebebi değildir. Genel olarak, nedenler üç topara ayrılabilir:

Dış veya işletim sistemi bellek baskısı

Dış baskı, sürecin dışındaki bir bileşenden gelen yüksek bellek kullanımını ifade eder ve bu da SQL Server için yetersiz belleğe yol açar. Sistemdeki diğer uygulamaların bellek tüketip düşük bellek kullanılabilirliğine katkıda bulunup bulunmadığını bulmalısınız. SQL Server, işletim sistemi bellek baskısına karşı bellek kullanımını azaltarak yanıt veren az sayıdaki uygulamadan biridir. Bu, bir uygulama veya sürücü bellek istediğinde, işletim sistemi tüm uygulamalara bellek boşaltmak için sinyal gönderir ve SQL Server kendi bellek kullanımını azaltır. Diğer çok az uygulama yanıt verir çünkü bu bildirimi dinlemek için tasarlanmamışlardır. Yani SQL bellek kullanımını azaltmaya başlarsa, bellek havuzu azalır ve belleğe ihtiyaç duyan bileşenler bunu alamayabilir. 701 ve diğer bellek kaynaklı hatalar almaya başlıyorsunuz. Daha fazla bilgi için bkz. SQL Server Bellek Mimarisi

Dahili bellek baskısı, SQL Server'dan gelmiyor

İç bellek baskısı, SQL Server işlemi içindeki faktörlerin neden olduğu düşük bellek kullanılabilirliğini ifade eder. SQL Server sürecinin içinde çalışabilen ve SQL Server motoruna "dış" bileşenler vardır. Örnekler arasında bağlı sunucular, SQLCLR bileşenleri, genişletilmiş prosedürler (XP) ve OLE Otomasyonu (sp_OA*) gibi DLL'ler bulunur. Diğerleri ise izleme amacıyla bir sürece DLL'ler enjekte eden antivirüs veya diğer güvenlik programlarını içerir. Bu bileşenlerin herhangi birinde bir sorun veya kötü tasarım, büyük bellek tüketimine yol açabilir. Örneğin, harici bir kaynaktan gelen 20 milyon satırlık veriyi SQL Server belleğine önbellekleyen bağlı bir sunucuyu düşünün. SQL Server açısından, hiçbir bellek memuru yüksek bellek kullanımı rapor etmez, ancak SQL Server sürecinde tüketilen bellek yüksek olur. Örneğin, bağlı bir sunucu DLL'sinden gelen bu bellek büyümesi, SQL Server'ın bellek kullanımını azaltmaya başlamasına neden olur (yukarıya bakınız) ve SQL Server içindeki bileşenler için düşük bellek koşulları yaratır, bu da 701 gibi hatalara yol açar.

SQL Server bileşenlerinden gelen dahili bellek baskısı

SQL Server Engine içindeki bileşenlerden gelen dahili bellek baskısı da 701 hatasına yol açabilir. sys.dm_os_memory_clerks üzerinden takip edilen yüzlerce bileşen SQL Server içinde bellek tahsis ediyor. Bunu daha fazla çözebilmek için hangi bellek memurlarının en büyük bellek tahsisatlarından sorumlu olduğunu belirlemeniz gerekir. Örneğin, OBJECTSTORE_LOCK_MANAGER bellek memurunun büyük bellek tahsisini gösterdiğini görürseniz, Lock Manager'ın neden bu kadar çok bellek tükettiğini daha iyi anlamanız gerekir. Birçok kilidi edinip indeksler kullanarak optimize eden, uzun süre kilitleri tutan işlemleri kısaltan veya kilit yükseltmenin devre dışı kalıp kalmadığını kontrol eden sorgular bulabilirsiniz. Her hafıza memuru veya bileşeni, belleğe erişme ve kullanma konusunda benzersiz bir yönteme sahiptir. Daha fazla bilgi için sys.dm_os_memory_clerks ve açıklamalarına bakınız.

Kullanıcı eylemi

701 hatası ara sıra veya kısa bir süre için ortaya çıkarsa, kısa süreli bir bellek sorunu kendi kendine çözülebilir. Bu durumlarda harekete geçmenize gerek olmayabilir. Ancak, hata birden fazla bağlantıda birden fazla kez meydana gelirse ve saniyeler veya daha uzun süreler devam ederse, daha fazla sorun giderme için adımları izleyin.

Aşağıdaki liste, bellek hatalarının giderilmesine yardımcı olacak genel adımları özetlemektedir.

Tanı araçları ve yakalama

Sorun giderme verisini toplamanızı sağlayacak tanı araçları Performans İzleyicisi, sys.dm_os_memory_clerks ve DBCC MEMORYSTATUS'dur.

Aşağıdaki sayaçları Performans İzleyicisi ile yapılandırın ve toplayın:

  • Bellek: Kullanılabilir MB
  • İşlem:Çalışma Kümesi
  • İşlem:Özel Baytlar
  • SQL Server:Memory Manager: (tüm sayaçlar)
  • SQL Server:Buffer Manager: (tüm sayaçlar)

Bu sorgunun periyodik çıktılarını etkilenen SQL Server'da toplayın

SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC

Pssdiag veya SQL LogScout

Bu veri noktalarını yakalamanın alternatif ve otomatik bir yolu ise PSSDIAG veya SQL LogScout gibi araçları kullanmaktır.

  • Pssdiag kullanıyorsanız, Perfmon koleksiyoncuyu ve Özel Diagnostics\SQL Bellek Hata Toplayıcısını yakalamak için yapılandırın
  • SQL LogScout kullanıyorsanız, Bellek senaryosunu yakalayacak şekilde yapılandırın

Aşağıdaki bölümler her senaryo için daha ayrıntılı adımları - harici veya dahili bellek baskısını - açıklar.

Dış baskı: tanı ve çözümler

  • SQL Server süreci dışındaki sistemdeki düşük bellek koşullarını teşhis etmek için Performans monitör sayacı toplayın. SQL Server dışındaki uygulamalar veya hizmetlerin bu sunucuda bellek tüketip tüketmediğini şu sayaçlara bakarak araştırın:

    • Bellek: Kullanılabilir MB
    • İşlem:Çalışma Kümesi
    • İşlem:Özel Baytlar

    İşte PowerShell kullanılarak bir Perfmon günlük koleksiyonu örneği

    clear
    $serverName = $env:COMPUTERNAME
    $Counters = @(
       ("\\$serverName" +"\Memory\Available MBytes"),
       ("\\$serverName" +"\Process(*)\Working Set"),
       ("\\$serverName" +"\Process(*)\Private Bytes")
    )
    
    Get-Counter -Counter $Counters -SampleInterval 2 -MaxSamples 1 | ForEach-Object  {
    $_.CounterSamples | ForEach-Object       {
       [pscustomobject]@{
          TimeStamp = $_.TimeStamp
          Path = $_.Path
          Value = ([Math]::Round($_.CookedValue, 3)) }
    }
    }
    
  • Sistem Olay günlüğünü inceleyin ve belleğe bağlı hatalar (örneğin, düşük sanal bellek) arayın.

  • Uygulamayla ilgili bellek sorunları için Uygulama Olay günlüğünü gözden geçirin.

    İşte "memory" anahtar kelimesi için Sistem ve Uygulama Olay kayıtlarını sorgulamak için örnek bir PowerShell betikleri. Aramanız için "kaynak" gibi diğer dizeleri kullanabilirsiniz:

    Get-EventLog System -ComputerName "$env:COMPUTERNAME" -Message "*memory*"
    Get-EventLog Application -ComputerName "$env:COMPUTERNAME" -Message "*memory*"
    
  • Daha az kritik uygulamalar veya hizmetler için kod veya yapılandırma sorunlarını gidererek bellek kullanımını azaltmak.

  • SQL Server dışındaki uygulamalar kaynak tüketiyorsa, bu uygulamaları durdurmayı veya yeniden planlamayı deneyin, ya da ayrı bir sunucuda çalıştırmayı düşünün. Bu adımlar harici bellek baskısını ortadan kaldıracaktır.

SQL Server'dan gelmediği dahili bellek baskısı: tanı ve çözümler

SQL Server içindeki modüller (DLL) nedeniyle oluşan dahili bellek baskısını teşhis etmek için aşağıdaki yaklaşımı kullanın:

  • SQL Server Belleğe Sayfaları Kilitle seçeneğini (AWE API) kullanmıyorsa, belleğinin çoğu Performans İzleyicisi'daki Process:Private Bytes sayacında (SQLServrörneğin) yansıtılır. SQL Server motoru içinden gelen genel bellek kullanımı, SQL Server:Memory Manager: Total Server Memory (KB) sayacında yansıtılır. Eğer Process:Private Bytes ile SQL Server:Memory Manager: Total Server Memory (KB) değeri arasında önemli bir fark bulursanız, bu fark muhtemelen bir DLL'den (bağlı sunucu, XP, SQLCLR vb.) kaynaklanıyordur. Örneğin, Özel baytlar 300 GB ve Toplam Sunucu Belleği 250 GB ise, süreçteki toplam belleğin yaklaşık 50 GB'ı SQL Server motorunun dışından gelir.

  • Eğer SQL Server Bellekte Sayfaları Kilitle (AWE API) kullanıyorsa, sorunu tespit etmek daha zor çünkü Performans Monitörü bireysel süreçler için bellek kullanımını takip eden AWE sayacı sunmuyor. SQL Server motoru içinden gelen genel bellek kullanımı, SQL Server:Memory Manager: Total Server Memory (KB) sayacında yansıtılır. Tipik İşlem:Özel Bayt değerleri genel olarak 300 MB ile 1-2 GB arasında değişebilir. Eğer bu tipik kullanım dışında Process:Private Baytların önemli bir kullanımı bulursanız, fark muhtemelen bir DLL'den (bağlı sunucu, XP, SQLCLR vb.) kaynaklanıyordur. Örneğin, Özel bayt sayacı 5-4 GB isese ve SQL Server Belleğe Sayfaları Kilitlemiyorsa (AWE), Özel baytların büyük bir kısmı SQL Server motorunun dışından gelebilir. Bu bir yaklaştırma tekniğidir.

  • SQL Server alanında yüklenen DLL'leri tanımlamak için Tasklist aracını kullanın:

    tasklist /M /FI "IMAGENAME eq sqlservr.exe"
    
  • Ayrıca bu sorguyu yüklü modülleri (DLL'ler) incelemek ve orada bir şeyin beklenti olup olmadığını görmek için de kullanabilirsiniz

    SELECT * FROM sys.dm_os_loaded_modules
    
  • Bir Linked Server modülünün önemli bir bellek tüketimine neden olduğunu düşünüyorsanız, Allow inprocess seçeneğini devre dışı bırakarak modülün işlem dışı kalmasını yapılandırabilirsiniz. Daha fazla bilgi için Bağlantılı sunucular oluştur (SQL Server Database Engine) bölümüne bakınız. Tüm bağlı sunucu OLEDB sağlayıcıları süreçten çıkmaz; Daha fazla bilgi için ürün üreticisiyle iletişime geçin.

  • OLE otomasyon nesneleri nadiren kullanıldığı durumlarda (sp_OA*), bağlam = 4 (Sadece Yerel (.exe) OLE sunucusu) ayarlayarak nesneyi SQL Server dışındaki bir süreçte çalıştıracak şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz. sp_OACreate.

SQL Server motoru tarafından dahili bellek kullanımı: tanı ve çözümler

  • SQL Server:SQL Server:Buffer Manager, SQL Server: Memory Manager için performans monitörü sayaclarını toplamaya başlayın.

  • SQL Server bellek memurlarını DMV'ye birkaç kez sorgulayarak motorda en yüksek bellek tüketiminin nerede gerçekleştiğini görün:

    SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
    FROM sys.dm_os_memory_clerks
    ORDER BY pages_kb DESC
    
  • Alternatif olarak, daha ayrıntılı DBCC MEMORYSTATUS çıktısını ve bu hata mesajlarını gördüğünüzde nasıl değiştiğini gözlemleyebilirsiniz.

    DBCC MEMORYSTATUS
    
  • Hafıza memurları arasında açık bir suçlu tespit ederseniz, o bileşen için bellek tüketiminin ayrıntılarını ele almaya odaklanın. İşte birkaç örnek:

    • Eğer MEMORYCLERK_SQLQERESERVATIONS bellek memuru bellek tüketiyorsa, büyük bellek hibeleri kullanan sorguları belirleyin ve bunları indeksler aracılığıyla optimize edin, yeniden yazın (örneğin ORDER'ı kaldırın) veya sorgu ipuçları uygulayın.
    • Eğer çok sayıda ad hoc sorgu planı önbelleğe alınırsa, CACHESTORE_SQLCP bellek memuru büyük miktarda bellek kullanır. Sorgu planları tekrar kullanılamayan parametresiz sorguları belirleyin ve bunları ya depolanmış prosedürlere dönüştürerek, ya da , ya sp_executesqlda ZORUNLU parametreleştirme kullanarak parametreleştirin.
    • Eğer nesne planı önbellek deposu CACHESTORE_OBJCP çok fazla bellek tüketiyorsa, şunları yapın: hangi depolanmış prosedürlerin, fonksiyonların veya tetikleyicilerin çok fazla bellek kullandığını belirleyin ve uygulamayı yeniden tasarlayın. Genellikle bu, her birinde yüzlerce prosedür bulunan büyük miktarda veritabanı veya şema nedeniyle olabilir.
    • Eğer OBJECTSTORE_LOCK_MANAGER bellek memuru büyük bellek tahsisatlarını gösteriyorsa, birçok kilidi uygulayan sorguları belirleyin ve bunları indeksler kullanarak optimize edin. Belirli izolasyon seviyelerinde uzun süre kilitlerin açılmamasına neden olan işlemleri kısaltın veya kilit yükseltmenin devre dışı kalıp olmadığından kontrol edin.

Hızlı bir rahatlama olabilir ki hafıza kullanılabilir hale gelebilir

Aşağıdaki işlemler bir miktar belleği boşaltabilir ve SQL Server'a kullanılabilir hale getirebilir:

  • Aşağıdaki SQL Server bellek yapılandırma parametrelerini denetleyin ve mümkünse maksimum sunucu belleğini artırmayı göz önünde bulundurun:

    • en fazla sunucu belleği

    • en az sunucu belleği

      Olağan dışı ayarlara dikkat edin. Bunları gerektiği gibi düzeltin. Artan bellek gereksinimlerini hesaba katın. Varsayılan ayarlar Sunucu bellek yapılandırma seçeneklerinde listelenir.

  • Özellikle Lock sayfalarını bellekteen fazla sunucu belleği yapılandırmadıysanız, işletim sistemi için biraz bellek tanımak için belirli bir değer ayarlamayı düşünün. Bellek sunucusunun yapılandırmasında sayfaları kilitleme seçeneğine bakınız.

  • Sorgu iş yükünü kontrol edin: eşzamanlı oturum sayısı, şu anda yürütülen sorgular ve geçici olarak durdurulabilecek veya başka bir SQL Server'a taşınabilecek daha az kritik uygulamalar olup olmadığını görün.

  • SQL Server'ı sanal makinede (VM) çalıştırıyorsanız, VM için belleğin aşırı yüklenmediğinden emin olun. VM'ler için bellek yapılandırması hakkında fikirler için , şu bloga bakabilirsiniz: Sanallaştırma – Aşırı Bağlanan Bellek ve VM içinde nasıl tespit edilir ve ESX/ESXi sanal makine performans sorunları (bellek aşırı yüklenmesi)

  • Aşağıdaki DBCC komutlarını çalıştırarak birkaç SQL Server bellek önbelleğini boşaltabilirsiniz.

    • DBCC FREESYSTEMCACHE komutu, sistem önbelleğini temizlemek için kullanılır.

    • DBCC FREESESSIONCACHE

    • DBCC FREEPROCCACHE

  • Resource Governor kullanıyorsanız, kaynak havuzu veya iş yükü grup ayarlarını kontrol etmenizi ve hafızayı çok kısıtlamadıklarını görmenizi öneririz.

  • Sorun devam ederse, daha fazla araştırma yapmanız ve muhtemelen sunucu kaynaklarını (RAM) artırmanız gerekecek.