Tempdb'ye dosya ekleme bağlamında sıcak tespit nedir?

SQL Server hizmetini yeniden başlatmak zorunda kalmadan bir SQL Server tempdb dosyaları eklemek mümkün olup olmadığını bulmaya çalışıyorum. Bu yanıtı burada Veritabanı Yöneticileri'nde gördüm:

• Tempdb Dosya ekle yeniden başlat gerektirir

Ve bir cevap şöyle diyor:

EKLE - kesinti gerekmez. Microsoft'tan Sean'ın işaret ettiği gibi, SQL daha düşük doldurulmuş dosyaları kullanmayı tercih edecektir. 1 veri dosyasından gidip daha fazlasını ekliyorsanız, SQL bir süreliğine yenilerini kullanacaktır, ancak performansınız yalnızca bir dosyaya sahip olmaktan daha kötü olmayacaktır. Bununla birlikte, zaten 2+ sürümünüz varsa ve bir tane daha eklerseniz, yeni olana hotspot olur ve performansı düşürür.

Ancak, bir yorum aşağıdakileri uyarır:

"Ekle" kısmına bir zeyilname eklerdim: "Ekle: Hayır, ama büyük olasılıkla dengesiz kalacaksınız, bu yüzden her şeyi daha da kötüleştirecek sıcak lekelenme olacaksınız."

Bu yorumla ilgili aşağıdaki sorularım var, ancak bu soruya cevapları yorumla sormak yerine bu soruları kendime (bu soru) yeni bir soruda sorması talimatı verildi.

özellikle:

1. Sıcak lekelenme nedir? (Google üzerinden bilgi aldım, ancak dosya ekledikten sonra tempdb'de etkin nokta ile ne olacağını ayrıntılı olarak bilmiyorum)
2. Sıcak lekelenme tempdb'de işleri daha da kötüleştirir mi?
3. DB'deki belirli şeyler çok daha kötü olur?

1. Sıcak lekelenme nedir?

   Bu bağlamda "sıcak nokta belirleme", tempdb'de birden çok dosya olmasına rağmen, tüm G / Ç çalışmalarının tek bir dosyada yapıldığını gösterir. Tempdb, dosya eklemeyi haklı çıkaracak kadar meşgulse, sıcak lekelenmeye yol açan dengesizlik ( orantılı dolum nedeniyle ) kısa ömürlü olacaktır, bu yüzden uyarıların biraz Tavuk Biraz olabileceğini düşünüyorum. Benim tecrübelerime göre, neyse.

2. Sıcak lekelenme tempdb'de işleri daha da kötüleştirir mi?

   Bence tempdb'de daha kötü sayılır, çünkü çoğu iş yükünde yazma aktivitesini zorlaştırır. Kullanıcı veritabanlarında kesinlikle benzer sorunlar yaşayabilirsiniz, ancak zaten tempdb'de bir sorunu çözmeye çalıştığınız için ...

3. DB'deki belirli şeyler çok daha kötü olur?

   Çoğunlukla yazma zamanları. Yakınlarda 7 ATM olsa bile herkesin aynı ATM'yi kullanmaya çalıştığını düşünün. Herhangi bir zamanda ancak bu kadar çok şey yazılabilir; her şey beklemek zorunda. Daha fazla dosya (ve işi planlamak için yeterli çekirdek) ile G / Ç daha eşit bir şekilde yayılabilir.

   Sadece emin ol:

   • çift ​​sayıda dosyanız var
   • tüm dosyalar aynı boyutta
   • tüm dosyalar aynı otomatik büyüme ayarlarına sahiptir
   • dosya sayısı bir şekilde çekirdek sayısı tarafından yönlendirilir
   • sürüme bağlı olarak (bunlar SQL Server'ın daha modern sürümlerinde varsayılan olarak etkindir ), izleme bayraklarını 1117 (tüm veri dosyalarını bir kerede büyüt ) ve 1118 (karma ayırma uzantıları kullanmayın) kullanıyorsunuz.

1. Sıcak lekelenme nedir?

Aaron doğrudur ve yukarıda söylediklerini yeniden şekillendirmeyeceğim, ancak bu sadece disk IO ile ilgili değil. Çoğu insanın TempDB'de sorun yaşadığı ana kısım, belirli izleme yapılarındaki çekişmelerden kaynaklanmaktadır.

Birden fazla tempdb dosyasına sahip olmak, orantılı dolgu ve yuvarlak robin algoritmalarının ayırmalar arasında "adil" olmada etkili bir şekilde yer almasına izin verdiğinden, ayırma olmadan yeni bir dosya eklemek bunu bir parça atar. PAGELATCH_*Bahsedilen yeni dosyada beklemeleri görmeye başlarsanız , diğer dosyalarda çok fazla veya herhangi bir şey görmüyorsanız, bunun bir "tavuk küçük" uyarısı olduğuna (aşağıdaki ürün güncellemelerine bakın) katılmıyorum . Bu genellikle TempDB etkinliği yüksek olan ve zaten tek bir dosyadan daha fazlasına sahip olan sistemlerde olur.

SQL Server 2019'da temel sistem tablolarından bazılarını bellek içi tablolara dönüştürmek için seçenekler bulunduğunu unutmayın; bellek içi nesneler disk fırında tablolardan farklı olarak ayrıldığından bu durum iyileştirilebilir. Disk tabanlı tablolar, yıllar boyunca birlikte çalıştığımız geleneksel tablolardır. SQL Server 2014, bellek için optimize edilmiş tablolar tanıttı . SQL Server 2019, bellek için optimize edilmiş tablolardaki bazı ayırma meta verilerini işleyebilir.

Eşzamanlı PFS değişikliklerine yardımcı olmak için SQL Server 2019'da başka bir değişiklik yapıldı, bu genellikle ayırmadaki bellek içi yapı için PAGELATCH_*çekişmenin beklediği şeydir .

2. Sıcak lekelenme tempdb'de işleri daha da kötüleştirir mi?

Hiçbir şey IMHO. Evet, TempDB, doğrudan kullanılmadan yazmaya neden olabilecek daha fazla öğeye sahiptir, böylece bazı öğeleri engelleyebilir. Ancak, veri değişim hızı açısından çok yoğun bir kullanıcı veritabanı da aynı derecede kötü. Sadece TempDB ile sınırlı değil.

3. DB'deki belirli şeyler çok daha kötü olur?

Aaron'ın benzetmesini gerçekten çok seviyorum! Olanların özü budur. Daha da kötüsü, veritabanındaki nesneler için alan tahsisi ve izlemesidir. Kullanıcı veritabanınız çoğunlukla statikse (düşük değişim oranı) veya TempDB'niz gerçekten kullanılmıyorsa, hiçbir şey fark etmezsiniz. Bununla birlikte, oldukça meşgul bir sunucuysa, konvoyları engellemeye yol açabilecek pagelatch beklemelerini başlatabilir veya şiddetlendirebilirsiniz.

Aaron zaten eski sürümde, tekdüze uzantıların kullanıldığından ve bir dosya grubundaki tüm dosyaların birlikte büyüdüğünden emin olmak için izleme bayrakları olduğunu belirtti (Aaron, 2016'da NOP olan 1117 ve 1118'i işaret ediyor). Tekrar belirtmek istediğim bir diğer şey, bunun sadece TempDB için değil, herhangi bir veritabanı için olduğu ve fiziksel düzenin ihtiyaçlara bağlı olarak düşünülmesi gerektiğidir.

Bu yalnızca etkin nokta ile ilgili sorunlar için değil, aynı zamanda yedekleme / geri yükleme, dosya yönetimi, dosya sistemi meta veri parçalanması vb. Gibi birden çok dosyaya sahip olmanıza yardımcı olabilecek diğer bölümler için de geçerlidir.

waitresourceBir PFS sayfasında (sayfa 1 ve sonra her 8088 sayfada bir) arayarak tahsis yapısı çekişmesini görebilirsiniz . Hepsini aynı dosyada (2: dosya: sayfa) görürseniz, bunun gerçekleştiğini bilirsiniz.