Bellek yönetimi mimarisi kılavuzu

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Windows Sanal Bellek Yöneticisi

Adres alanının kaydedilmiş bölgeleri, Windows Virtual Memory Manager (VMM) tarafından kullanılabilir fiziksel belleğe eşlenir.

Farklı işletim sistemleri tarafından desteklenen fiziksel bellek miktarı hakkında daha fazla bilgi için Windows Sürümleri için Bellek Sınırları ile ilgili Windows belgelerine bakın.

Sanal bellek sistemleri fiziksel belleğin aşırı taahhüdünü sağlar, böylece sanal bellek ile fiziksel bellek oranı 1:1'i aşabilir. Sonuç olarak, çeşitli fiziksel bellek yapılandırmalarına sahip bilgisayarlarda daha büyük programlar çalıştırılabilir. Ancak, tüm işlemlerin ortalama çalışma kümelerinden önemli ölçüde daha fazla sanal bellek kullanmak düşük performansa neden olabilir.

SQL Server bellek mimarisi

SQL Server, gerektiğinde belleği dinamik olarak alır ve boşaltabilir. Genellikle, seçenek hala mevcut olmasına ve bazı ortamlarda gerekli olmasına rağmen, bir yöneticinin SQL Server'a ne kadar bellek ayrılması gerektiğini belirtmesi gerekmez.

Tüm veritabanı yazılımlarının birincil tasarım hedeflerinden biri disk G/Ç'sini en aza indirmektir çünkü disk okuma ve yazma işlemleri en yoğun kaynak kullanımlı işlemler arasındadır. SQL Server, veritabanından okunan sayfaları tutmak için bellekte bir arabellek havuzu oluşturur. SQL Server'daki kodun çoğu disk ile arabellek havuzu arasındaki fiziksel okuma ve yazma sayısını en aza indirmeye ayrılmıştır. SQL Server iki hedef arasında bir denge kurmaya çalışır:

• Arabellek havuzunun, sistemin genelinde bellek yetersizliğine yol açacak kadar büyümesini önleyin.
• Arabellek havuzunun boyutunu en üst düzeye çıkararak veritabanı dosyalarındaki fiziksel G/Ç'yi azaltın.

Yoğun olarak yüklenen bir sistemde, çalıştırmak için büyük miktarda bellek gerektiren bazı büyük sorgular istenen en düşük bellek miktarını alamaz ve bellek kaynaklarını beklerken zaman aşımı hatası alır. Bu sorunu çözmek için sorgu bekleme seçeneğini artırın. Paralel sorgu için en yüksek paralellik derecesini azaltmayı göz önünde bulundurun.

Bellek baskısı altında yoğun olarak yüklenen bir sistemde, sorgu planında birleştirme, sıralama ve bit eşlem içeren sorgular bit eşlem için gereken en düşük belleği almadığında bit eşlemi bırakabilir. Bu, sorgu performansını etkileyebilir ve sıralama işlemi belleğe sığmazsa, veritabanındaki çalışma tablolarının tempdb kullanımını artırarak büyümesine neden olabilir tempdb . Bu sorunu çözmek için fiziksel bellek ekleyin veya sorguları farklı ve daha hızlı bir sorgu planı kullanacak şekilde ayarlayın.

Geleneksel (sanal) bellek

Tüm SQL Server sürümleri 64 bit platformda geleneksel belleği destekler. SQL Server işlemi, x64 mimarisinde işletim sistemi üst sınırına kadar sanal adres alanına erişebilir.

Uyarı

SQL Server 2025 (17.x) sürümünden itibaren SQL Server Standard sürümü 256 GB'a kadar destekler. SQL Server 2022 (16.x) ve önceki sürümlerde SQL Server Standard sürümü 128 GB'a kadar destekler.

IA64 mimarisinde sınır 7 TB 'dı (IA64 SQL Server 2012 (11.x) ve sonraki sürümlerde desteklenmez).

Daha fazla bilgi için bkz. Windows için Bellek Sınırları.

Windows Uzantıları (AWE) belleğini adresle

Adres Pencereleme Uzantıları (AWE) ve AWE tarafından gereken Sayfaları belleğe kilitle (LPIM) ayrıcalığını kullanarak SQL Server işlem belleğinin çoğunu düşük sanal bellek koşullarında fiziksel RAM'de kilitli tutabilirsiniz. Bu, hem 32 bit hem de 64 bit AWE ayırmalarında gerçekleşir. Belleğin kilitlenmesi, AWE belleğinin belleğin sayfalanmasını kontrol eden Windows'daki Sanal Bellek Yöneticisi'nden geçmemesinden kaynaklanır. AWE bellek ayırma API Sayfaları bellekte kilitleme (SeLockMemoryPrivilege) ayrıcalığı gerektirir; Bkz. AllocateUserPhysicalPages notları. Bu nedenle, AWE API'sini kullanmanın temel avantajı, sistemde bellek baskısı varsa belleğin çoğunu RAM'de tutmaktır. SQL Server'ın AWE kullanmasına izin verme hakkında bilgi için bkz. Sayfaları bellekte kilitle seçeneğini (Windows) etkinleştirme.

LPIM verilirse, varsayılan değeri 2.147.483.647 megabayt (MB) bırakmak yerine belirli bir değere ayarlamanızı max server memory (MB) kesinlikle öneririz. Daha fazla bilgi için bkz . Sunucu belleği yapılandırma seçenekleri: Seçenekleri el ile ayarlama ve Sayfaları belleğe kilitleme (LPIM).

LPIM etkinleştirilmediyse, SQL Server geleneksel bellek kullanmaya ve işletim sistemi bellek tükenmesi durumlarında geçiş yapar ve hata günlüğünde MSSQLSERVER_17890 hatası bildirilebilir. Hata aşağıdaki örneğe benzer:

A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

SQL Server 2012'den başlayarak bellek yönetiminde yapılan değişiklikler

SQL Server'ın eski sürümlerinde bellek ayırma işlemi beş farklı mekanizma kullanılarak yapılmıştır:

• Single-Page Ayırıcısı (SPA), yalnızca SQL Server işleminde 8 KB'tan küçük veya buna eşit bellek ayırmaları içerir. max server memory (MB) ve min server memory (MB) yapılandırma seçenekleri, SPA'nın tüketilen fiziksel bellek sınırlarını belirledi. Arabellek Havuzu hem SPA'nın mekanizması, hem de tek sayfa ayırımlarının en büyük tüketicisiydi.

• Çok Sayfalı Ayırıcı (MPA), 8 KB'tan fazla bellek tahsisleri için.

• CLR Ayırıcısı, SQL CLR yığınları ve CLR başlatılması sırasında oluşturulan genel ayırmalar dahil.

• SQL Server işlemindeki iş parçacığı yığınları için bellek ayırmaları.

• Doğrudan Windows Ayırmaları (DWA), doğrudan Windows'a yapılan bellek ayırma istekleri içindir. Bunlar Windows yığın kullanımını ve SQL Server işlemine yüklenen modüller tarafından yapılan doğrudan sanal ayırmaları içerir. Bu tür bellek ayırma isteklerine örnek olarak genişletilmiş saklı yordam DLL'lerinden ayırmalar, Otomasyon yordamları (sp_OA çağrılar) kullanılarak oluşturulan nesneler ve bağlı sunucu sağlayıcılarından ayırmalar verilebilir.

SQL Server 2012 (11.x) ile başlayarak Single-Page ayırmaları, Çok Sayfalı ayırmalar ve CLR ayırmalarının tümü "Herhangi bir boyutta" Sayfa Ayırıcısı içinde birleştirilir ve ve max server memory (MB) yapılandırma seçenekleri tarafından min server memory (MB) denetlenen bellek sınırlarına eklenir. Bu değişiklik, SQL Server bellek yöneticisinden geçen tüm bellek gereksinimleri için daha doğru bir boyutlandırma özelliği sağladı.

Önemli

SQL Server 2012 (11.x) ve max server memory (MB) sonraki sürümlerine yükseltdikten sonra geçerli min server memory (MB) ve yapılandırmalarınızı dikkatle gözden geçirin. Bunun nedeni SQL Server 2012 (11.x) sürümünden başlayarak bu tür yapılandırmaların önceki sürümlerle karşılaştırıldığında daha fazla bellek ayırmayı içermesi ve hesaba eklemesidir. Bu değişiklikler SQL Server 2012 (11.x) ve SQL Server 2014 (12.x) ve SQL Server 2016 (13.x) ve sonraki sürümlerin hem 32 bit hem de 64 bit sürümleri için geçerlidir.

Aşağıdaki tablo, ve yapılandırma seçenekleri tarafından max server memory (MB)min server memory (MB) belirli bir bellek ayırma türünün denetlenip denetlenmediğini gösterir:

Bellek ayırma türü	SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) ve SQL Server 2008 R2 (10.50.x)	SQL Server 2012 'den (11.x) başlayarak
Tek sayfalık tahsisler	Evet	Evet, "herhangi bir boyutta" sayfa ayırmaları içine birleştirilmiş durumda.
Çok sayfalı tahsisatlar	Hayı	Evet, "herhangi bir boyutta" sayfa ayırmaları içine birleştirilmiş durumda.
CLR ayırmaları	Hayı	Evet
İş parçacığı yığın belleği	Hayı	Hayı
Windows'tan doğrudan ayrımlar	Hayı	Hayı

SQL Server, maksimum sunucu belleği ayarı üzerinden bellek işleyebilir

SQL Server 2012 (11.x) ile başlayarak, SQL Server ayarda max server memory (MB) belirtilen değerden daha fazla bellek ayırabilir. Bu davranış, tarafından belirtildiği gibi Toplam Sunucu Belleği (KB) değeri max server memory (MB) ayarına zaten ulaştığında oluşabilir. Bellek parçalanması nedeniyle çok sayfalı bellek isteklerinin (8 KB'den fazla) talebini karşılamak için bitişik boş bellek yetersizse, SQL Server bellek isteğini reddetmek yerine fazla taahhüt gerçekleştirebilir.

Bu ayırma gerçekleştirilir gerçekleşmez, Kaynak İzleyicisi arka plan görevi tüm bellek tüketicilerine ayrılan belleği serbest bırakmaları için sinyal vermeye başlar ve Toplam Sunucu Belleği (KB) değerini Hedef Sunucu Belleği (KB) belirtiminin altına getirmeye çalışır. Bu nedenle, SQL Server bellek kullanımı kısa bir süre ayarı max server memory (MB) aşabilir. Bu durumda, Toplam Sunucu Belleği (KB) performans sayacı okuması ve max server memory (MB) ayarlarını aşıyor.

Bu davranış genellikle aşağıdaki işlemler sırasında gözlemlenir:

• Büyük columnstore dizin sorguları
• Rowstore'da büyük toplu mod sorguları
• Columnstore dizinlerini yeniden inşa eden işlemler, Karma ve Sıralama işlemlerini gerçekleştirmek için büyük hacimli bellek kullanır.
• Büyük bellek arabellekleri gerektiren yedekleme işlemleri
• Büyük giriş parametrelerini depolaması gereken izleme işlemleri
• Büyük bellek alanı talepleri

Bu davranışı sık sık gözlemlerseniz, Kaynak İzleyicisi'nin daha hızlı temizlenebilmesi için SQL Server 2019'da (15.x) izleme bayrağı 8121 kullanmayı göz önünde bulundurun. SQL Server 2022 'den (16.x) başlayarak, bu işlev varsayılan olarak etkindir ve izleme bayrağının hiçbir etkisi yoktur.

SQL Server 2012'den itibaren, 'memory_to_reserve' değişiklikleri

SQL Server'ın eski sürümlerinde, SQL Server bellek yöneticisi çok Sayfalı Ayırıcı (MPA), CLR Ayırıcısı, SQL Server işlemindeki iş parçacığı yığınları için bellek ayırmaları ve Doğrudan Windows ayırmaları (DWA) tarafından kullanılmak üzere işlem sanal adres alanının (VAS) bir bölümünü ayırmış. Sanal adres alanının bu bölümü "Mem-To-Leave" veya "Arabelleksiz Havuz" bölgesi olarak da bilinir.

Bu ayırmalar için ayrılmış sanal adres alanı yapılandırma seçeneği tarafından memory_to_reserve belirlenir. SQL Server'ın kullandığı varsayılan değer 256 MB'tır.

"Herhangi bir boyut" sayfa ayırıcısı 8 KB'tan büyük ayırmaları da işlediğinden, memory_to_reserve değer çok sayfalı ayırmaları içermez. Bu değişiklik dışında, diğer her şey bu yapılandırma seçeneğinde aynı kalır.

Aşağıdaki tablo, belirli bir bellek ayırma türünün SQL Server işlemi için sanal adres alanının bölgesine düşüp düşmediğini memory_to_reserve gösterir:

Bellek ayırma türü	SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) ve SQL Server 2008 R2 (10.50.x)	SQL Server 2012 'den (11.x) başlayarak
Tek sayfalık tahsisler	Hayı	Hayır, "herhangi bir boyutta" sayfa ayırmalarında birleştirilmiş
Çok sayfalı tahsisatlar	Evet	Hayır, "herhangi bir boyutta" sayfa ayırmalarında birleştirilmiş
CLR ayırmaları	Evet	Evet
İş parçacığı yığın belleği	Evet	Evet
Windows'tan doğrudan ayrımlar	Evet	Evet

Dinamik bellek yönetimi

SQL Server Veritabanı Altyapısı'nın varsayılan bellek yönetimi davranışı, sistemde bellek yetersizliği oluşturmadan gerektiği kadar bellek almaktır. SQL Server Veritabanı Altyapısı bunu Microsoft Windows'taki Bellek Bildirimi API'lerini kullanarak yapar.

SQL Server belleği dinamik olarak kullandığında, boş bellek miktarını belirlemek için sistemi düzenli aralıklarla sorgular. Bu boş belleğin korunması işletim sisteminde (İS) sayfalamayı önler. Daha az bellek boşsa, SQL Server belleği işletim sistemine bırakır. Daha fazla bellek boşsa, SQL Server daha fazla bellek ayırabilir. SQL Server yalnızca iş yükü daha fazla bellek gerektirdiğinde bellek ekler; bekleyen bir sunucu, sanal adres alanının boyutunu artırmaz. SQL Server dinamik bellek yönetimi kullanırken Görev Yöneticisi ve Performans İzleyicisi'nin kullanılabilir bellekte sabit bir azalma gösterdiğini fark ederseniz, bu varsayılan davranıştır ve bellek sızıntısı olarak algılanmıyor olmalıdır.

Sunucu bellek yapılandırma seçenekleri SQL Server bellek ayırmayı, derleme belleğini, tüm önbellekleri (arabellek havuzu dahil), sorgu yürütme belleği vermelerini, kilit yöneticisi belleğini ve CLR¹ belleğini ( temelde sys.dm_os_memory_clerks bulunan herhangi bir bellek katibini) denetler.

¹ CLR belleği, SQL Server 2012 (11.x) ile başlayan ayırmalar altında max server memory (MB) yönetilir.

Aşağıdaki sorgu, şu anda ayrılmış bellekle ilgili bilgileri döndürür:

SELECT physical_memory_in_use_kb / 1024 AS sql_physical_memory_in_use_MB,
       large_page_allocations_kb / 1024 AS sql_large_page_allocations_MB,
       locked_page_allocations_kb / 1024 AS sql_locked_page_allocations_MB,
       virtual_address_space_reserved_kb / 1024 AS sql_VAS_reserved_MB,
       virtual_address_space_committed_kb / 1024 AS sql_VAS_committed_MB,
       virtual_address_space_available_kb / 1024 AS sql_VAS_available_MB,
       page_fault_count AS sql_page_fault_count,
       memory_utilization_percentage AS sql_memory_utilization_percentage,
       process_physical_memory_low AS sql_process_physical_memory_low,
       process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;

Yığın boyutları

İş parçacığı yığınları ¹, CLR ², genişletilmiş yordam .dll dosyaları için bellek, dağıtılmış sorgular tarafından başvurulan OLE DB sağlayıcıları, Transact-SQL deyimlerinde başvurulan otomasyon nesneleri ve SQL Server DLL olmayan bir tarafından ayrılan bellekler tarafından max server memory (MB).

¹ Geçerli konaktaki belirli sayıda affinitized CPU için hesaplanan varsayılan çalışan iş parçacıkları hakkında bilgi için Sunucu yapılandırması: maksimum çalışan iş parçacıklarına bakın. SQL Server yığın boyutları aşağıdaki gibidir:

SQL Server mimarisi	İşletim sistemi mimarisi	Yığın boyutu
x86 (32 bit)	x86 (32 bit)	512 KB
x86 (32 bit)	x64 (64 bit)	768 KB
x64 (64 bit)	x64 (64 bit)	2.048 KB
IA64 (Itanium)	IA64 (Itanium)	4.096 KB

² CLR belleği, SQL Server 2012 (11.x) ile başlayan ayırmalar altında max server memory (MB) yönetilir.

SQL Server, SQL Server bellek yöneticisinin bellek ve yayın belleğini ne zaman ayırabileceğini belirlemek için bellek bildirim API'sini QueryMemoryResourceNotification kullanır.

SQL Server başlatıldığında, arabellek havuzu için sanal adres alanının boyutunu sistemdeki fiziksel bellek miktarı, sunucu iş parçacığı sayısı ve çeşitli başlangıç parametreleri gibi çeşitli parametrelere göre hesaplar. SQL Server, arabellek havuzu için süreç sanal adres alanının hesaplanan miktarını rezerv eder, ancak mevcut yük için yalnızca gerekli miktarda fiziksel bellek edinir (işler).

Ardından örnek, iş yükünü desteklemek için gereken belleği almaya devam eder. Daha fazla kullanıcı sorguya bağlandıkça ve sorgu çalıştırdıkça, SQL Server isteğe bağlı olarak daha fazla fiziksel bellek alır. SQL Server örneği, ayırma hedefine max server memory (MB) ulaşana kadar fiziksel bellek almaya devam eder veya işletim sistemi artık fazla boş bellek olmadığını gösterir; en düşük sunucu belleği ayarından daha fazla olduğunda bellek boşaltılır ve işletim sistemi boş bellek yetersizliği olduğunu gösterir.

Sql Server örneğini çalıştıran bir bilgisayarda diğer uygulamalar başlatıldığından, bellek tüketir ve boş fiziksel bellek miktarı SQL Server hedefinin altına düşer. SQL Server örneği bellek tüketimini ayarlar. Başka bir uygulama durdurulursa ve daha fazla bellek kullanılabilir hale gelirse, SQL Server örneği bellek ayırma boyutunu artırır. SQL Server her saniye birkaç megabayt bellek boşaltıp alabilir ve bellek ayırma değişikliklerine hızla uyum sağlamasına olanak sağlar.

En az ve en fazla sunucu belleğinin etkileri

En düşük sunucu belleği ve en yüksek sunucu belleği yapılandırma seçenekleri, veritabanı altyapısının arabellek havuzu ve diğer önbellekleri tarafından kullanılan bellek miktarı için üst ve alt sınırlar oluşturur. Arabellek havuzu, en düşük sunucu belleğinde belirtilen bellek miktarını hemen almaz. Arabellek havuzu yalnızca başlatmak için gereken bellekle başlar. SQL Server Veritabanı Altyapısı iş yükü arttıkça, iş yükünü desteklemek için gereken belleği edinmeye devam eder. Arabellek havuzu, en düşük sunucu belleğinde belirtilen miktara ulaşana kadar alınan belleğin hiçbirini boşaltmaz. En düşük sunucu belleğine ulaşıldıktan sonra arabellek havuzu, gerektiğinde bellek almak ve boşaltmak için standart algoritmayı kullanır. Tek fark, arabellek havuzunun bellek ayırmasını hiçbir zaman en düşük sunucu belleğinde belirtilen düzeyin altına bırakmaması ve hiçbir zaman içinde belirtilen düzeyden daha fazla bellek almamasıdır max server memory (MB).

Uyarı

İşlem olarak SQL Server, seçenek tarafından max server memory (MB) belirtilenden daha fazla bellek alır. Hem iç hem de dış bileşenler arabellek havuzunun dışında bellek ayırabilir ve bu da ek bellek tüketir, ancak arabellek havuzuna ayrılan bellek genellikle SQL Server tarafından kullanılan belleğin en büyük bölümünü temsil eder.

SQL Server Veritabanı Altyapısı tarafından alınan bellek miktarı tamamen örneğe yerleştirilen iş yüküne bağlıdır. Çok fazla istek işlemez bir SQL Server örneği tarafından min server memory (MB)belirtilen değere asla ulaşamayabilir.

Hem en düşük sunucu belleği max server memory (MB)hem de için aynı değer belirtilirse, SQL Server Veritabanı Altyapısı'na ayrılan bellek bu değere ulaştığında, SQL Server Veritabanı Altyapısı arabellek havuzu için dinamik olarak bellek boşaltmayı ve almayı durdurur.

Sql Server örneği, diğer uygulamaların sık sık durdurulduğu veya başlatıldığı bir bilgisayarda çalışıyorsa, SQL Server örneği tarafından belleğin ayrılması ve serbest bırakılması diğer uygulamaların başlangıç sürelerini yavaşlatabilir. Ayrıca, SQL Server tek bir bilgisayarda çalışan çeşitli sunucu uygulamalarından biriyse, sistem yöneticileri SQL Server'a ayrılan bellek miktarını denetlemelidir. Bu gibi durumlarda, SQL Server'ın ne kadar bellek kullanabileceğini denetlemek için en düşük sunucu belleğini ve max server memory (MB) seçeneklerini kullanabilirsiniz. min server memory (MB) ve max server memory (MB) seçenekleri megabayt cinsinden belirtilir. Bu bellek yapılandırmalarını ayarlama hakkında öneriler de dahil olmak üzere daha fazla bilgi için bkz . Sunucu bellek yapılandırma seçenekleri.

SQL Server nesne özellikleri tarafından kullanılan bellek

Aşağıdaki listede, SQL Server'daki farklı nesneler tarafından kullanılan yaklaşık bellek miktarı açıklanmaktadır. Listelenen tutarlar tahmindir ve ortama ve nesnelerin nasıl oluşturulduğuna bağlı olarak değişebilir:

• Kilit (Kilit Yöneticisi tarafından korunduğu şekilde): 64 bayt + Sahip başına 32 bayt
• Kullanıcı bağlantısı: Yaklaşık (3 * network_packet_size + 94 KB)

Ağ paketi boyutu, uygulamalarla Veritabanı Altyapısı arasında iletişim kurmak için kullanılan tablosal veri akışı (TDS) paketlerinin boyutudur. Varsayılan paket boyutu 4 KB'tır ve ağ paket boyutu yapılandırma seçeneği tarafından denetlenır.

Birden çok etkin sonuç kümesi (MARS) etkinleştirildiğinde, kullanıcı bağlantısı yaklaşık olarak (3 + 3 * num_logical_connections) * network_packet_size + 94 KB olur.

Sorgu başına en az belleğin etkileri

Yapılandırma seçeneği, min memory per query sorgunun yürütülmesi için ayrılacak en düşük bellek miktarını (kilobayt cinsinden) belirler. Bu, en düşük bellek verme olarak da bilinir. Tüm sorguların istenen en düşük belleğin güvenliği sağlanıncaya kadar, yürütmenin başlayabilmesi için veya sorgu bekleme sunucusu yapılandırma seçeneğinde belirtilen değer aşılana kadar beklemesi gerekir. Bu senaryoda biriken bekleme türü: RESOURCE_SEMAPHORE.

Önemli

Özellikle çok meşgul sistemlerde sunucu yapılandırma seçeneğini çok yüksek ayarlamayın min memory per query , çünkü bunu yapmak şunlara yol açabilir:

• Bellek kaynakları için artan rekabet.
• Çalışma zamanında gerekli bellek bu yapılandırmadan daha düşük olsa bile her sorgu için bellek miktarını artırarak eşzamanlılığı azaltın.

Bu yapılandırmayı kullanma hakkında öneriler için bkz . Sunucu yapılandırması: sorgu başına en az bellek.

Bellek tahsisi değerlendirmeleri

Satır modu yürütmesi için, başlangıç bellek izni herhangi bir koşul altında aşılamaz. Başlangıçta verilen bellek izninden daha fazla bellek gerekiyorsa, karma veya sıralama işlemleri disk üzerine taşınır. Taşan bir karma işlemi tempdbWorkfile tarafından desteklenirken, taşan bir sıralama işlemi Worktable tarafından desteklenir.

Sıralama işlemi sırasında oluşan bir taşma, Sıralama Uyarıları Olay Sınıfı olarak bilinir. Sıralama uyarıları, sıralama işlemlerinin belleğe sığmadığını gösterir. Bu, dizin oluşturmayla ilgili sıralama işlemlerini içermez, yalnızca sorgu içindeki sıralama işlemlerini (deyiminde ORDER BY kullanılan bir SELECT yan tümcesi gibi) içerir.

Karma işlemi sırasında oluşan bir taşma, Karma Uyarı Olay Sınıfı olarak bilinir. Karma işlemi sırasında bir karma özyineleme veya karmayı sonlandırma (karma kurtarma) gerçekleştiğinde bunlar oluşur.

• Karma özyineleme, derleme girişi kullanılabilir belleğe sığmadığında oluşur ve girişin ayrı olarak işlenen birden çok bölüme bölünmesine neden olur. Bu bölümlerden herhangi biri hala kullanılabilir belleğe sığmıyorsa, alt bölümlere bölünür ve bunlar da ayrı olarak işlenir. Bu bölme işlemi, her bölüm kullanılabilir belleğe sığana kadar veya en yüksek özyineleme düzeyine ulaşılana kadar devam eder.
• Karma kurtarma, bir karma oluşturma işlemi en yüksek özyineleme düzeyine ulaştığında ve kalan bölümlenmiş verileri işlemek için alternatif bir plana geçmeye karar verdiğinde gerçekleşen bir mekanizmadır. Bu olaylar sunucunuzda performansın düşmesine neden olabilir.

Toplu iş modu yürütme için, ilk bellek ataması varsayılan olarak belirli bir iç eşiğe kadar dinamik olarak artabilir. Bu dinamik bellek verme mekanizması, toplu iş modunda çalışan karma veya sıralama işlemlerinin bellekte yerleşik olarak yürütülmesine izin verecek şekilde tasarlanmıştır. Bu işlemler hala belleğe sığmıyorsa, işlemler diske taşar.

Yürütme modları hakkında daha fazla bilgi için bkz. Sorgu İşleme Mimarisi Kılavuzu.

Arabellek yönetimi

SQL Server veritabanının birincil amacı verileri depolamak ve almaktır, bu nedenle yoğun disk G/Ç Veritabanı Altyapısı'nın temel bir özelliğidir. Disk G/Ç işlemlerinin çok fazla kaynak tüketebildiği ve tamamlanması görece uzun sürebileceği için SQL Server, G/Ç'yi son derece verimli hale getirmek için odaklanır. Arabellek yönetimi, bu verimliliğe ulaşmada önemli bir bileşendir. Arabellek yönetimi bileşeni iki mekanizmadan oluşur: veritabanı sayfalarına erişmek ve güncelleştirmek için arabellek yöneticisi ve veritabanı dosyası G/Ç'sini azaltmak için arabellek önbelleği ( arabellek havuzu olarak da adlandırılır).

SQL Server'da disk G/Ç'sinin ayrıntılı açıklaması için bkz. SQL Server G/Ç temelleri.

Arabellek yönetimi nasıl çalışır?

Arabellek, bellekte veri veya dizin sayfasıyla aynı boyutta olan 8 KB'lık bir sayfadır. Bu nedenle, arabellek önbelleği 8 KB'lık sayfalar olarak ayrılır. Arabellek yöneticisi, veritabanı disk dosyalarındaki verileri veya dizin sayfalarını arabellek önbelleğine okuma ve değiştirilen sayfaları diske geri yazma işlevlerini yönetir. Arabellek yöneticisi daha fazla veri okumak için arabellek alanına ihtiyaç duyana kadar bir sayfa arabellek önbelleğinde kalır. Veriler yalnızca değiştirildiğinde diske geri yazılır. Önbellekteki veriler, diske geri yazılmadan önce birden çok kez değiştirilebilir. Daha fazla bilgi için bkz. Veritabanı Altyapısı'ndaki veri sayfalarını okuma ve Veritabanı Altyapısı'ndaki Yazma sayfaları.

SQL Server başlatıldığında, arabellek önbelleği için sanal adres alanının boyutunu sistemdeki fiziksel bellek miktarı, yapılandırılan en fazla sunucu iş parçacığı sayısı ve çeşitli başlangıç parametreleri gibi çeşitli parametrelere göre hesaplar. SQL Server, işlem sanal adres alanının hesaplanan bu miktarını (bellek hedefi olarak adlandırılır) arabellek önbelleği için ayırır, ancak geçerli yük için yalnızca gerekli miktarda fiziksel belleği kullanır (taahhüt eder). Sys.dm_os_sys_info committed_target_kb ve committed_kb sütunlarını sorgulayarak bellek hedefi olarak ayrılmış sayfa sayısını ve arabellek önbelleğinde o anda işlenen sayfa sayısını döndürebilirsiniz.

SQL Server'ın başlatılması ile arabellek önbelleğinin bellek hedefine ulaşması arasındaki aralık, ramp-up olarak adlandırılır. Bu süre boyunca, gerektiğinde okuma istekleri arabellekleri doldurur. Örneğin, tek bir 8 KB sayfa okuma isteği tek bir arabellek sayfasını doldurur. Bu, artırma işleminin istemci isteklerinin sayısına ve türüne bağlı olduğu anlamına gelir. Artış hızı, tek sayfa okuma isteklerinin hizalanmış sekiz sayfa isteğine (tek bir kapsam oluşturan) dönüştürülmesiyle hızlandırılır. Bu, özellikle çok fazla belleğe sahip makinelerde rampanın çok daha hızlı bitmesini sağlar. Sayfalar ve kapsamlar hakkında daha fazla bilgi için bkz. Sayfalar ve Kapsamlar Mimarisi Kılavuzu.

Arabellek yöneticisi SQL Server işlemindeki belleğin çoğunu kullandığından, diğer bileşenlerin arabelleklerini kullanmasına izin vermek için bellek yöneticisiyle birlikte kullanılır. Arabellek yöneticisi öncelikle aşağıdaki bileşenlerle etkileşim kurar:

• Genel bellek kullanımını ve 32 bit platformlarda adres alanı kullanımını denetlemek için Resource Manager.
• Alt düzey dosya G/Ç işlemleri için Veritabanı Yöneticisi ve SQL Server İşletim Sistemi (SQLOS).
• İleri yazma günlüğü için Günlük Yöneticisi.

Desteklenen özellikler

Arabellek yöneticisi aşağıdaki özellikleri destekler:

• Arabellek yöneticisi tekdüzen olmayan bellek erişimi (NUMA) bilincindedir. Arabellek önbellek sayfaları, bir iş parçacığının, yabancı bellek yerine yerel NUMA düğümünde ayrılan bir arabellek sayfasına erişmesine olanak tanıyan bir şekilde donanım NUMA düğümleri arasında dağıtılır.

• Arabellek yöneticisi, kullanıcıların sunucuyu yeniden başlatmadan fiziksel bellek eklemesine olanak tanıyan Dinamik Bellek Ekleme'yi destekler.

• 64 bit platformlarda arabellek yöneticisi büyük sayfaları destekler. Sayfa boyutu Windows sürümüne özgüdür.

  Uyarı

  SQL Server 2012 (11.x) öncesinde, SQL Server'da büyük sayfaları etkinleştirmek için izleme bayrağı 834 gerekir.

• Arabellek yöneticisi, ek tanılamaları dinamik yönetim görünümleri aracılığıyla kullanıma sunar. SQL Server'a özgü çeşitli işletim sistemi kaynaklarını izlemek için bu görünümleri kullanabilirsiniz. Örneğin, arabellek önbelleğindeki sayfaları izlemek için sys.dm_os_buffer_descriptors görünümünü kullanabilirsiniz.

Bellek baskısı algılama

Bellek baskısı, bellek yetersizliklerinden kaynaklanan bir koşuldur ve aşağıdakilere neden olabilir:

• Ek G/Ç'ler (yoğun olarak aktif tembel yazar arka plan iş parçacığı gibi)
• Daha yüksek yeniden derleme oranı
• Daha uzun çalışan sorgular (bellek verme beklemeleri varsa)
• Ek CPU döngüleri

Bu durum dış veya iç nedenler tarafından tetiklenebilir. Dış nedenler şunlardır:

• Kullanılabilir fiziksel bellek (RAM) düşük. Bu, sistemin çalışmakta olan işlemlerin çalışma kümelerini kırpmasına neden olur ve bu da genel yavaşlamayla sonuçlanabilir. SQL Server arabellek havuzunun işleme hedefini azaltabilir ve iç önbellekleri daha sık kırpmaya başlayabilir.
• Genel kullanılabilir sistem belleği (sistem sayfası dosyasını içerir) düşük. Bu, sistemin bellek ayırmalarında başarısız olmasına neden olabilir çünkü şu anda ayrılmış belleğin sayfasını çıkaramaz.

İç nedenler şunlardır:

• SQL Server Veritabanı Altyapısı daha düşük bellek kullanım üst sınırı belirlediğinde dış bellek baskısına yanıt verme.
• Maksimum sunucu bellek yapılandırması azaltılarak bellek ayarları el ile düşürülüyordu.
• Birkaç önbellek arasındaki iç bileşenlerin bellek dağılımındaki değişiklikler.

SQL Server Veritabanı Altyapısı, dinamik bellek yönetimi kapsamında bellek baskısını algılamaya ve işlemeye ayrılmış bir çerçeve uygular. Bu çerçeve, Kaynak İzleyicisi adlı arka plan görevini içerir. Kaynak İzleyicisi görevi, dış ve iç bellek göstergelerinin durumunu izler. Bu göstergelerden biri durumu değiştirdikten sonra ilgili bildirimi hesaplar ve yayımlar. Bu bildirimler, motor bileşenlerinin her birinden gelen ve halka arabelleklerinde depolanan iç iletilerdir.

İki kademe arabelleği, dinamik bellek yönetimiyle ilgili bilgileri tutar:

• Kaynak İzleyicisi halka arabelleği, bellek baskısının sinyallenip sinyallenmediği gibi Kaynak İzleyicisi etkinliklerini izler. Bu halka arabellek, RESOURCE_MEMPHYSICAL_HIGH, RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADY veya RESOURCE_MEMVIRTUAL_LOW'ün geçerli durumuna bağlı olarak durum bilgisine sahiptir.

• Her bir Resource Governor kaynak havuzu için bellek bildirimlerinin kayıtlarını içeren Memory Broker halka arabelleği. İç bellek baskısı algılandıkçe, belleği önbellekler arasında dengelemeye yönelik eylemleri tetikleme amacıyla bellek ayıran bileşenler için düşük bellek bildirimi açılır.

Bellek aracıları her bileşen tarafından bellek tüketimini izler ve toplanan bilgilere göre bu bileşenlerin her biri için belleğin en uygun değerini hesaplar. Her bir Resource Governor kaynak havuzu için bir dizi komisyoncu vardır. Bu bilgiler daha sonra bileşenlerin her birine yayınlanır ve bu da kullanımlarını gerektiği gibi büyütür veya küçültür.

Bellek aracıları hakkında daha fazla bilgi için bkz. sys.dm_os_memory_brokers.

Hata algılama

Veritabanı sayfaları, diske yazıldığı zamandan yeniden okunana kadar sayfanın bütünlüğünü sağlamaya yardımcı olmak için iki isteğe bağlı mekanizmadan birini kullanabilir: parçalanmış sayfa koruması ve sağlama toplamı koruması. Bu mekanizmalar yalnızca veri depolamanın değil, denetleyiciler, sürücüler, kablolar ve hatta işletim sistemi gibi donanım bileşenlerinin doğruluğunu doğrulamak için bağımsız bir yöntem sağlar. Koruma, diske yazmadan hemen önce sayfaya eklenir ve diskten okunduktan sonra doğrulanır.

SQL Server sağlama toplamı, bozuk sayfa veya diğer G/Ç hatasıyla başarısız olan tüm okumaları dört kez yeniden denenir. Yeniden deneme girişimlerinden herhangi birinde okuma başarılı olursa, hata günlüğüne bir ileti yazılır ve okuma işlemini tetikleyen komut devam eder. Yeniden deneme girişimleri başarısız olursa, komut MSSQLSERVER_824 hatasıyla başarısız olur.

Kullanılan sayfa koruması türü, sayfayı içeren veritabanının özniteliğidir. Sağlama toplamı koruması, SQL Server 2005 (9.x) ve sonraki sürümlerde oluşturulan veritabanları için varsayılan korumadır. Sayfa koruma mekanizması veritabanı oluşturma zamanında belirtilir ve kullanılarak ALTER DATABASE SETdeğiştirilebilir. page_verify_option katalog görünümündeki sütunu veya IsTornPageDetectionEnabled işlevinin özelliğini sorgulayarak geçerli sayfa koruma ayarını belirleyebilirsiniz.

Uyarı

Sayfa koruma ayarı değiştirilirse, yeni ayar veritabanının tamamını hemen etkilemez. Bunun yerine sayfalar, bir sonraki yazıldığında veritabanının geçerli koruma düzeyini benimser. Bu, veritabanının farklı koruma türlerine sahip sayfalardan oluşabileceği anlamına gelir.

Yırtılmış sayfa koruması

SQL Server 2000'de (8.x) kullanıma sunulan yırtılmış sayfa koruması, öncelikle güç kesintilerinden kaynaklanan sayfa bozulmalarını algılamanın bir yoludur. Örneğin, beklenmeyen bir güç kesintisi diske yazılmış bir sayfanın yalnızca bir bölümünü bırakabilir. Yırtılmış sayfa koruması kullanıldığında, 8 kilobayt (KB) veritabanı sayfasındaki her 512 baytlık kesim için belirli bir 2 bit imza deseni kullanılır ve sayfa diske yazıldığında veritabanı sayfası üst bilgisinde depolanır.

Sayfa diskten okunduğunda, sayfa üst bilgisinde depolanan kopmuş bitler gerçek sayfa kesimi bilgileriyle karşılaştırılır. İmza düzeni ikili 01 ile 10 her yazma arasında geçiş yaptığından, kesimlerin yalnızca bir bölümünün diske ne zaman geldiğini anlamak her zaman mümkündür: Sayfa daha sonra okunduğunda bir bit yanlış durumdaysa, sayfa yanlış yazılmış ve yırtılmış bir sayfa algılanır. Yırtılmış sayfa algılama en az kaynak kullanır; ancak, disk donanım hatalarının neden olduğu tüm hataları algılamaz. Bozuk sayfa algılamayı ayarlama hakkında bilgi için bkz. ALTER DATABASE SET Options.

Checksum koruması

SQL Server 2005 (9.x) ile sunulan sağlama toplamı koruması, daha güçlü veri bütünlüğü denetimi sağlar. Yazılan her sayfada, veriler için bir sağlama toplamı hesaplanır ve sayfa üst bilgisinde depolanır. Depolanan sağlama toplamına sahip bir sayfa diskten her okunduğu zaman, veritabanı altyapısı sayfadaki verilerin sağlama toplamını yeniden hesaplar ve yeni sağlama toplamı depolanan sağlama toplamından farklıysa 824 hatasını oluşturur. Sağlama toplamı koruması, sayfanın her baytından etkilendiği için yırtık sayfa korumasından daha fazla hata yakalayabilir, ancak kaynak kullanımı açısından orta yoğunluktadır.

Sağlama toplamı etkinleştirildiğinde, güç kesintileri ve hatalı donanım veya üretici yazılımından kaynaklanan hatalar, arabellek yöneticisi diskten bir sayfa okuduğunda algılanabilir. Sağlama toplamını ayarlama hakkında bilgi için bkz. ALTER DATABASE SET Options komutu.

Önemli

Bir kullanıcı veya sistem veritabanı SQL Server 2005 (9.x) veya sonraki bir sürüme yükseltildiğinde , PAGE_VERIFY değeri (NONE veya TORN_PAGE_DETECTION) korunur. kullanmanızı CHECKSUMkesinlikle öneririz. TORN_PAGE_DETECTION daha az kaynak kullanabilir, ancak korumanın CHECKSUM en düşük alt kümesini sağlar.

Tekdüzen olmayan bellek erişimini anlama

SQL Server, tekdüzen olmayan bellek erişimine (NUMA) duyarlıdır ve özel yapılandırma olmadan NUMA donanımında iyi performans gösterir. Saat hızı ve işlemci sayısı arttıkça, bu ek işlem gücünü kullanmak için gereken bellek gecikme süresini azaltmak giderek zorlaşır. Bunu aşmak için donanım satıcıları büyük L3 önbellekleri sağlar, ancak bu yalnızca sınırlı bir çözümdür. NUMA mimarisi bu soruna ölçeklenebilir bir çözüm sağlar.

SQL Server, herhangi bir uygulama değişikliği gerektirmeden NUMA tabanlı bilgisayarlardan yararlanacak şekilde tasarlanmıştır. Daha fazla bilgi için bkz. Soft-NUMA (SQL Server).

Bellek nesnelerinin dinamik bölümü

SQL Server'da bellek nesneleri olarak bilinen yığın ayırıcıları, Veritabanı Altyapısı'nın yığından bellek ayırmasına izin verir. Bunlar sys.dm_os_memory_objects DMV kullanılarak izlenebilir.

CMemThread , birden çok iş parçacığından eşzamanlı bellek ayırmalarına izin veren, iş parçacığı açısından güvenli bir bellek nesnesi türüdür. Doğru izleme için nesneler, CMemThread tek bir iş parçacığının kritik bilgi parçalarını aynı anda güncelleştirdiğinden emin olmak için eşitleme yapılarına (bir mutex) dayanır.

Uyarı

CMemThread Nesne türü, veritabanı altyapısı kod tabanında birçok farklı ayırma için kullanılır ve düğüme veya CPU'ya göre genel olarak bölümlenebilir.

Ancak, çok sayıda iş parçacığı aynı bellek nesnesinden son derece eşzamanlı bir şekilde ayrılırsa, mutex'lerin kullanılması çekişmeye neden olabilir. Bu nedenle, SQL Server bölümlenmiş bellek nesneleri (PMO) kavramına sahiptir ve her bölüm tek CMemThread bir nesneyle temsil edilir. Bellek nesnesinin bölümlenmesi statik olarak tanımlanır ve oluşturulduktan sonra değiştirilemez. Bellek ayırma desenleri donanım ve bellek kullanımı gibi yönlere göre büyük ölçüde değiştiğinden, mükemmel bölümleme desenini önceden bulmak mümkün değildir.

Çoğu durumda, tek bir bölüm kullanmak yeterlidir, ancak bazı senaryolarda bu çekişmeye neden olabilir ve bu yalnızca yüksek oranda bölümlenmiş bir bellek nesnesiyle önlenebilir. Daha fazla bölüm diğer verimsizliklere neden olabileceği ve bellek parçalanma oranını artıraaabildiği için her bellek nesnesini bölümlendirmek istenmez.

Uyarı

SQL Server 2016(13.x) öncesinde, düğüm tabanlı bir PMO'ya CPU tabanlı PMO olmaya zorlamak için izleme bayrağı 8048 kullanılabilir. SQL Server 2014 (12.x) SP2 ve SQL Server 2016 (13.x) ile başlayarak, bu davranış dinamiktir ve altyapı tarafından denetlenilir.

SQL Server 2014 (12.x) SP2 ve SQL Server 2016 (13.x) ile başlayarak, Veritabanı Altyapısı belirli CMemThread bir nesnedeki çekişmeleri dinamik olarak algılayabilir ve nesneyi düğüm başına veya CPU tabanlı bir uygulamaya yükseltebilir. Yükseltildikten sonra, SQL Server işlemi yeniden başlatılana kadar PMO yükseltilmiş durumda kalır. CMemThread Çekişme, CMEMTHREAD DMV'de yüksek beklemenin varlığı ile ve sys.dm_os_memory_objects DMV sütunları contention_factor, partition_type, exclusive_allocations_count ve waiting_tasks_count gözlemlenerek algılanabilir.

İlgili içerik

• SQL Server G/Ç temelleri
• Sunucu belleği yapılandırma seçenekleri
• Veritabanı Altyapısı'nda veri sayfalarını okuma
• Veritabanı Altyapısı'nda sayfa yazma
• Soft-NUMA (SQL Server)
• Bellek için iyileştirilmiş tabloların kullanım gereksinimleri
• SQL Server'da yetersiz bellek sorunlarını giderme
• Yetersiz bellek sorunlarını çözme