TempDB Trafiğini Açmak: Allocation Contention ve Dosya Yönetimi

Bir önceki yazımda tempDB’yi SQL Server’ın karalama defteri, mutfak masası ve ortak tezgâhı olarak anlatmıştım. Şimdi bu defterin sayfalarında biraz daha derine inelim: Global temp table, local temp table ve allocation contention… Yani SQL Server’ın günlük hayatımızdaki beyaz tahtaları, kişisel kahve kupaları ve market kasaları.

🌍 Global Temp Table (##TempTable)

Global temp table kullanımı biraz daha özel senaryolara hitap eder. Çoğu durumda local temp table (#TempTable) yeterli olur; ama bazı durumlarda global temp table tercih etmek daha mantıklıdır:

• Birden Fazla Session Paylaşımı: Aynı anda birden fazla kullanıcı veya bağlantı aynı geçici tabloya erişmek istiyorsa global temp table devreye girer. Örneğin bir batch job tabloyu oluşturur, başka session’lar bu tabloyu okuyabilir.
• Uygulama Seviyesi Ortak Geçici Veri: Bir uygulamanın farklı modülleri aynı geçici tabloya ihtiyaç duyduğunda global temp table kullanılır. Örneğin raporlama uygulaması, farklı sorguların aynı tabloya yazıp okumasını sağlar.
• Test ve Debug Amaçlı: Birden fazla session’dan tabloya bakarak sorgu davranışını gözlemlemek için global temp table idealdir. DBA’ler performans sorunlarını incelerken bu yöntemi sıkça kullanır.
• Stored Procedure’ler Arası Paylaşım: Bir stored procedure global temp table oluşturur, başka stored procedure’ler aynı tabloyu kullanabilir.

🎒 Günlük Hayattan Örnekler:

1. Ortak Karalama Defteri: Düşün ki ofiste bir beyaz tahta var. Herkes gelip not yazabiliyor, toplantı bitene kadar orada duruyor. İş bitince siliniyor. İşte global temp table tam olarak bu: herkesin erişebildiği geçici tablo.
2. Paylaşılan WhatsApp Grubu: Arkadaşlarla buluşma planı yapıyorsun. Grup herkese açık, herkes mesaj atabiliyor. Buluşma bitince grup siliniyor. Global temp table da aynı şekilde, tüm session’lar görebiliyor ama iş bitince yok oluyor.
3. Ortak Mutfak Tezgâhı: Evde birden fazla kişi yemek yapıyor. Ortak tezgâhı kullanıyorlar, herkes malzemelerini koyuyor. Yemekler bitince tezgâh temizleniyor. Global temp table da SQL Server’ın ortak tezgâhı gibi.

💻 Gerçek Projelerden Örnekler:

1. Raporlama Sistemleri: Büyük bir şirkette günlük satış raporları hazırlanıyor. Bir job (arka plan görevi) satış verilerini ##SalesTemp tablosuna atıyor. Aynı anda farklı raporlama modülleri bu tabloyu okuyarak kendi raporlarını üretiyor. İş bitince tablo siliniyor.
2. ETL Süreçleri (Data Warehouse): Veri ambarına yükleme sırasında farklı paketler aynı geçici tabloya yazıp okuyor. Örneğin ##StagingTemp tablosu, farklı SSIS paketleri tarafından ortak kullanılıyor.
3. Test Ortamları: DBA’ler (Database Administrator) performans testleri yaparken global temp table açıp farklı session’lardan tabloya bakıyor. Böylece sorguların nasıl davrandığını gözlemleyebiliyorlar.
4. Çok Kullanıcılı Uygulamalar: Bir web uygulamasında kullanıcılar aynı anda rapor talep ediyor. Uygulama, geçici sonuçları global temp table’a yazıyor, farklı thread’ler aynı tabloyu okuyabiliyor.

☕ Local Temp Table (#TempTable)

Local temp table, tamamen kişisel kullanım için tasarlanmış geçici tablodur. Düşün ki ofiste herkesin kendi kahve kupası var: Sen kahveni içersin, işin bitince kupayı yıkarsın. Başkası kullanamaz. Local temp table da aynı şekilde sadece senin oturumunda vardır, işin bitince otomatik olarak silinir.

💻 Gerçek Projelerden Örnekler:

1. Stored Procedure İçinde Geçici Hesaplama: Bir stored procedure çalışırken ara sonuçları #TempTable içine atar. İşlem bitince tablo otomatik silinir, başka session göremez.
2. Raporlama Hazırlığı: Kullanıcı rapor almak için sorgu çalıştırır. Ara veriler #TempTable içine yazılır, rapor hazırlandıktan sonra tablo yok olur.
3. ETL Süreci (Kişisel): Veri yükleme sırasında sadece o paket için geçici tablo oluşturulur. Başka paketler bu tabloya erişemez.
4. Test Senaryoları: Geliştirici kendi session’ında #TempTable açar, sorguları test eder. Başka kullanıcılar aynı tabloyu göremez.

⚡ Allocation Contention

Kısaca: “CPU kadar tempDB dosyası oluşturulmalı” önerisi, SQL Server’da tempDB’de yaşanan kaynak çakışmalarını (allocation contention) azaltmak için geliştirilmiş bir performans tavsiyesidir. Ancak bu kural mutlak değildir; genellikle CPU sayısına yakın ama makul bir dosya sayısı önerilir.

🔍 Teknik Açıklama:

• Sorun: tempDB, SQL Server’ın en yoğun kullanılan sistem veritabanıdır. Çok sayıda session aynı anda tempDB’ye yazmaya çalıştığında, özellikle PFS, GAM ve SGAM sayfalarında “pagelatch contention” denilen kilitlenmeler oluşur.
• Çözüm: tempDB’yi birden fazla veri dosyasına bölmek. Böylece SQL Server farklı dosyalara yazabilir ve çakışmalar azalır.
• Öneri (Eskiden): “CPU sayısı kadar dosya” kuralı yaygındı. Örneğin 8 çekirdekli bir sunucuda 8 tempDB dosyası açmak.
• Güncel Yaklaşım (Microsoft artık daha esnek öneriyor):

Başlangıçta 4 dosya ile başla.

Eğer hâlâ contention varsa dosya sayısını CPU sayısına kadar artır.

Dosyaların eşit boyutlarda olması gerekir.

📊 Örnek Senaryolar:

· Sunucu 4 CPU: Başlangıçta 4 tempDB dosyası açılır. Çakışma yoksa artırmaya gerek yok.

· Sunucu 16 CPU: Önce 8 dosya açılır. Eğer hâlâ contention varsa 16’ya çıkarılır.

· Sunucu 64 CPU: Direkt 64 dosya açmak gereksizdir. Genellikle 16–32 dosya yeterli olur.

Günlük Hayattan Benzetme:

• Market Kasaları: Tek kasa varsa herkes sıraya girer, kuyruk oluşur. Birden fazla kasa açarsan müşteriler farklı kasalara dağılır. tempDB dosyalarını artırmak da aynı mantık: işlemler farklı dosyalara dağılır, kuyruk azalır.
• Otopark Girişleri: Tek giriş varsa trafik sıkışır. Birden fazla giriş açarsan arabalar farklı kapılardan girer. tempDB dosyaları da SQL Server’ın “otopark girişleri” gibidir.

⚠️ Dikkat Edilmesi Gerekenler:

• Aşırı Dosya Sayısı: CPU sayısı kadar dosya açmak her zaman doğru değil. Gereksiz dosya sayısı yönetim zorluğu ve disk I/O yükü yaratabilir.
• Eşit Boyut: Dosyaların boyutları aynı olmalı, yoksa SQL Server dengesiz dağıtır.
• Log Dosyası: tempDB’nin log dosyası tek kalır, sadece veri dosyaları çoğaltılır.

📌 Özet

“CPU kadar tempDB dosyası” önerisi, tempDB’deki kilitlenmeleri azaltmak için dosya sayısını CPU sayısına kadar artırabilirsin demektir. Ancak bu bir kural değil, ihtiyaca göre ayarlanması gereken bir tavsiyedir. Genellikle 4 dosya ile başlanır, contention varsa CPU sayısına kadar çıkılır.

Kaynakça:

1. https://gelecegiyazanlar.turkcell.com.tr/

Yazım burada sona eriyor. Eğer eklemek istediğiniz bir şeyler ya da düzeltilmesi gereken bir hata olduğunu düşünüyorsanız, benimle iletişime geçmekten çekinmeyin.