veriler için fiziksel bellek kalmadığında, SQL Server zaten varolan verileri TEMPDB'ye taşır
Bağlantı verdiğiniz makale en iyi şekilde yanıltıcı ve bazı yerlerde yanlış. Yazarın bazı karmaşık şeyleri aşırı basitleştirmeye çalıştığını düşünüyorum ve bunu yaparken biraz fazla ileri gitti.
SQL Server verileri bellekten (arabellek havuzu) bu şekilde tempdb'ye taşımaz. "En son kullanılan" önbellekleme stratejisini kullanır (genel olarak), bu nedenle bellek baskısı varsa ve yeni verilerin belleğe alınması gerekiyorsa, SQL Server, yeni verileri barındırmak için LRU verilerini arabellek havuzundan atacaktır. Bu davranış genellikle "Sayfa Yaşam Beklentisi" (PLE) adı verilen bir perfmon sayacı tarafından izlenir :
PLE'nin tanımı, arabellek havuzuna (veri dosyaları sayfalarının bellek içi önbelleği) okunan bir veri dosyası sayfasının farklı bir veri için yer açmak için bellekten çıkarılmadan önce bellekte kalacağı beklenen süredir. dosya sayfası. PLE'yi düşünmenin başka bir yolu, diskten okunan sayfalar için boş alan oluşturmak için arabellek havuzu üzerindeki baskının anlık bir ölçümüdür. Bu tanımların her ikisi için de daha yüksek bir sayı daha iyidir.
Sorgu yürütme sırasında SQL Server edebilirsiniz belirli işlemler için tempdb kullanın. Bu genellikle tahminler kötüyse yapılır, ancak kullanılabilir bellek yetersizliği bu davranışı etkileyebilir.
Bu şekilde tempdb'ye "dökülebilen" işlemlerden bazıları karma satırlar (birleştirmeler veya toplamalar vb. İçin), bellekteki satırları sıralamak ve paralel sorgu yürütme sırasında satırları arabelleğe almaktır.
Kullanıcı sorguları ayrıca açıkça tempdb (genel veya yerel geçici tablolarla) kullanabilir ve dolaylı olarak tempdb (anlık görüntü veya okunan anlık görüntü yalıtım düzeyleriyle) kullanabilir.
Bu durumların hiçbiri alıntıladığınız ifadeye uymuyor gibi görünüyor.
yeterli fiziksel bellek kalmadığında, işletim sistemi SAYFA DOSYASI'nı kullanabilir ve verileri fiziksel bellekten belleğe taşıyabilir
Bu kesinlikle olabilir ve çoğunlukla SQL Server'ın kontrolü dışındadır. Bazı işletim sistemi düzeyinde sayfalamayı önlemek için "Sayfaları Bellekte Kilitle" yi (LPIM) açmak için çevirebileceğiniz bir düğme vardır :
Bu Windows ilkesi, hangi hesapların verileri fiziksel bellekte tutmak için bir işlem kullanabileceğini belirler ve sistemin verileri diskteki sanal belleğe disk belleği olarak engellemesini önler.
Öyleyse diske disk belleği olarak kaydedilmesini ne engelleyebiliriz?
SQL Server 2012'den önce, "Tek Sayfa Ayırıcı" adı verilen bir bileşenle ayrılan sayfalar belleğe kilitlendi (sayfalanamadı). Buna arabellek havuzu (veritabanı sayfaları), yordam önbelleği ve diğer bazı bellek alanları da dahildir.
Ayrıntılar için, özellikle "4. Kilitli Sayfalar, AWE, Görev Yöneticisi ve Çalışma Kümesi ile Eğlenceli " bölümüne bakın. 4. Şimdi x64'teki SQL Server'ın "Kilitli Sayfalar" kullanabileceğini biliyorum, tam olarak kilitli olan nedir? " İlgili diğer okumaları burada bulabilirsiniz: Büyük SQL Server Tartışmaları: Bellekteki Sayfaları Kilitle
SQL Server 2012 ve sonraki sürümlerde "Tek Sayfa Ayırıcı" yoktur (tek ve çok sayfalı ayırıcılar , belleğe derinlemesine bakış - SQL Server 2012/2014 uyarınca birleştirilmiştir ). Tam olarak sayfalanıp neyin sayfalanamayacağına dair ayrıntılar, gördüğüm hiçbir yerde ayrıntılı olarak belgelenmez. Sen bir sorgu kullanabilirsiniz böyle olduğunu görmek için bir kilitli:
select osn.node_id, osn.memory_node_id, osn.node_state_desc, omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'
Aynı MS Support makalesine göre, DBCC MEMORYSTATUSne kadar belleğin "kilitlendiğini" görmek için de kullanabilirsiniz .
Yan not olarak, SQL Server'ın çalışma kümesinin işletim sistemi tarafından hata günlüğünde disk belleği olduğuna dair kanıtlar görebilirsiniz. Şuna benzeyen mesajlar olacak:
2019-09-02 10: 19: 27.29 spid11s sql sunucusu işlem belleğinin önemli bir kısmı çağrıldı. Bu, performansın düşmesine neden olabilir. Süre: 329 saniye. Çalışma kümesi (KB): 68780, taahhütlü (KB): 244052, bellek kullanımı:% 28.