TempDB yazma işlemleri her zaman diske gerçek bir fiziksel yazma ile sonuçlanır mı, yoksa TempDB yazma işlemleri Windows dosya sistemi önbelleğindeki gibi gecikmeli yazma için SQL Server tarafından önbelleğe alınmış mıdır?
Hep öyle mi? Kesinlikle hayır. Hiç yaptılar mı? Evet ama tipik mekanizmanın bir sonucu değil. Buradaki referans, tempdb için kontrol noktası ne işe yarar? .
"İyi davranış" bir sistemde, bir kullanıcı veritabanı dosyasına yazma denetim noktasında meydana gelir. Kötü davranılmış bir sistemde, tembel yazarın diğer sayfalara yer açmak için sayfaları arabellek havuzundan yıkaması gerektiğinde de yazılır.
Tempdb için yalnızca tempdb günlük dosyası% 70 dolu olduğunda bir denetim noktası yapılır - bu, mümkünse tempdb günlüğünün büyümesini önlemek içindir (uzun süren bir işlemin günlük rehin tutmaya devam edebileceğini ve temizlenmesini engelleyebileceğini unutmayın. , tıpkı bir kullanıcı veritabanında olduğu gibi).
Ancak tempdb'yi diske temizlemeye gerek yoktur, çünkü kilitlenme kurtarma asla tempdb'de çalıştırılmaz, her zaman başlangıçta yeniden oluşturulur.
Tempdb bir çökme durumunda kurtarılmaz ve bu nedenle, tembel yazma işleminin (arabellek havuzunun bir parçası) diğer veritabanlarından sayfalar için yer açmak zorunda kalması dışında, kirli tempdb sayfalarını diske zorlamaya gerek yoktur.
Bu dikkat çekici bir şekilde (benim için sürpriz oldu) tempdb sayfalarının diske yazılacağı tek mekanizmadır. Tampon havuzu basıncı varsa, tempdb sayfaları diske temizlenebilir. Eğer yoksa, gerçekleşmemelidir.
Düzenleme: "Kötü davranış" denetim noktası dışında sayfa yazan bir kullanıcı veritabanı için uygun bir açıklama olup olmadığı tartışmalı. Alışılmadık, atipik veya ideal değil belki?
Ek düzenleme (yorumları takip etme / @PaulWhite ile sohbet etme):
Yukarıdaki göze çarpan ihmal, geçici tabloların tek tempdb trafiği kaynağı olmamasıdır. Karma, Sırala ve Dökülme Olaylarını Anlamaktan Alıntı Yapma :
Bazı SQL Server sorgu yürütme işlemleri, ara depolama olarak (biraz) büyük miktarda bellek kullanılarak en iyi performansı gösterecek şekilde kalibre edilir. Sorgu Optimize Edici, bir plan seçecek ve bu bellek not defterini kullanarak bu operatörlere göre maliyeti tahmin edecektir. Ancak bu elbette sadece bir tahmindir. Yürütme sırasında tahminler yanlış olabilir ve yeterli hafızaya sahip olmamasına rağmen plan devam etmelidir. Böyle bir durumda, bu operatörler diske dökülür.
Yanlışlıkla bir dökülme operasyonu için fiziksel bir yazmanın arkasındaki mekanizmanın daha önce anlatıldığı gibi tamamen aynı olduğunu varsaymıştım (tembel yazar tempdb sayfalarını tampon havuzundaki (dökülmeden kaynaklanan) baskı sonucu diske zorlama).
@PaulWhite nerede olduğumu açıkladı (teşekkürler Paul!):
Bir sorgu sadece bellek tempdb kullanmak yerine, bir çalışma alanı bellek hibe aştığında fiziksel tempdb etkinliği neden olduğunu soruyorsun Bunu yaptı, sorguyu, bellek kısıtlama noktasını yenerek hibe daha fazla bellek kullanıyor olacaktır ilk etapta hibeler.
Dökülmeler gerçekten depolamaya kadar yazılıdır. Fiziksel tempdb aktivitesi, boş bellek yığında ve tempdb üzerinde sıfır basınç karşısında bile bir dökülmede görülür.
Paul ayrıca beni daha derinlemesine incelemek isteyenler için döküntüleri göstermek için örnek komutlar içeren Advanced TSQL Tuning: Internals Knowledge Matters neden blog yazısına dikkat çekti .