SQL Server TempDB Best Practice’leri: Dosya Sayısı, Boyut, Contention ve İzleme

Bir SQL Server instance’ındaki tüm veritabanları tek bir tempdb’yi paylaşır. Geçici tablolar, belleğe sığmayıp diske taşan sort’lar, hash join’ler, snapshot isolation için satır versiyonları, online index rebuild’ler: hepsi orada gerçekleşir. tempdb kötü yapılandırıldığında belirtiler her yerde aynı anda görülür: yavaş sorgular, allocation sayfalarında beklemeler ya da tüm instance’ı durduran dolu bir disk.

Bu rehberde güncel SQL Server sürümlerinde önemli olan tempdb best practice’lerini anlatıyoruz: kaç data dosyası kullanılmalı, nasıl boyutlandırılmalı, nereye konmalı, contention nasıl tanınır ve giderilir, SQL Server 2019, 2022 ve 2025’te neler değişti ve tempdb alanı bitmeden nasıl izlenir.

tempdb’de Neler Bulunur?

tempdb üç tür veri tutar:

• Kullanıcı nesneleri: yerel ve global geçici tablolar ve index’leri, table variable’lar, geçici stored procedure’ler, cursor’lar ve table-valued function’ların döndürdüğü tablolar.
• İç nesneler: engine’in spool, sort, hash join ve hash aggregate işlemleri için oluşturduğu work table ve work file’lar ile SORT_IN_TEMPDB kullanan index build’ler.
• Version store: READ_COMMITTED_SNAPSHOT ve SNAPSHOT isolation, online index işlemleri, MARS ve AFTER trigger’lar için satır versiyonları.

SQL Server, servis her başladığında tempdb’yi boş olarak yeniden oluşturur; bu yüzden yedeklenemez ve restore edilemez. Yapılandırılmış boyutunun önemli olmasının nedeni de budur: her restart’tan sonra tempdb bu boyuttan yeniden başlar.

Kaç tempdb Data Dosyası Olmalı?

Birden fazla data dosyası, tempdb’nin allocation sayfalarındaki contention’ı azaltır. Microsoft’un genel önerisi şöyledir:

• 8 veya daha az mantıksal işlemci varsa, mantıksal işlemci sayısı kadar data dosyası kullanın.
• 8’den fazla mantıksal işlemci varsa, 8 data dosyasıyla başlayın.
• Allocation contention hâlâ görülüyorsa, kabul edilebilir seviyeye inene kadar dosyaları 4’ün katları halinde artırın ya da iş yükünde değişiklik yapın.

Bu sorgu önerilen başlangıç noktasını instance’ın bugünkü durumuyla karşılaştırır:

SELECT i.cpu_count                                   AS logical_processors,
       CASE WHEN i.cpu_count <= 8 THEN i.cpu_count ELSE 8 END AS recommended_start,
       f.data_files                                  AS current_data_files,
       f.min_size_mb,
       f.max_size_mb
FROM sys.dm_os_sys_info AS i
CROSS JOIN (SELECT COUNT(*)              AS data_files,
                   MIN(size) * 8 / 1024  AS min_size_mb,
                   MAX(size) * 8 / 1024  AS max_size_mb
            FROM tempdb.sys.database_files
            WHERE type_desc = N'ROWS') AS f;

min_size_mb ile max_size_mb farklıysa data dosyalarınız aynı boyutta değildir; bu da en az dosya sayısı kadar önemlidir.

Dosya eklemek için yenilerini mevcutlarla aynı boyut ve büyüme ayarıyla oluşturun. Yeni dosyalar hemen kullanılmaya başlar; restart gerekmez:

-- Mevcut birincil data dosyasını hedef boyut ve büyümeye getir
ALTER DATABASE tempdb
MODIFY FILE (NAME = N'tempdev', SIZE = 8192MB, FILEGROWTH = 512MB);

-- Aynı ayarlarla ikinci bir dosya ekle (her yeni dosya için tekrarlayın)
ALTER DATABASE tempdb
ADD FILE (NAME = N'temp2',
          FILENAME = N'T:\TempDB\tempdb_mssql_2.ndf',
          SIZE = 8192MB,
          FILEGROWTH = 512MB);

tempdb’yi Varsayılana Göre Değil İş Yüküne Göre Boyutlandırın

Varsayılan tempdb dosyaları 8 MB boyutunda ve 64 MB büyümeyle gelir. Yoğun bir sunucuda bu, tempdb’nin her restart’tan sonra iş yükünün ihtiyaç duyduğu boyuta ulaşana kadar küçük adımlarla büyümesi demektir; her büyüme de onu tetikleyen sorguları bekletir.

• Önce ölçün. Index bakım job’larınız dahil temsili bir iş yükü çalıştırın, tempdb’nin en yüksek kullanımını izleyin ve dosyaların başlangıç boyutunu eşzamanlılık payıyla bunu karşılayacak şekilde ayarlayın.
• Autogrowth’u güvenlik ağı olarak açık tutun; her dosyada aynı, sabit bir MB değeriyle. Değerin nasıl seçileceğini autogrowth rehberimizde anlattık.
• SQL Server servis hesabı için instant file initialization’ı açın; böylece data dosyası büyümesi yeni alanı sıfırlamak zorunda kalmaz. SQL Server 2022’den beri 64 MB’a kadar log büyümeleri de bundan yararlanır.
• Log’u da boyutlandırın. tempdb log’u, tempdb kullanan uzun süreli transaction’ların log kayıtlarını tutar; küçük kalan bir log en kötü anda tekrar tekrar büyür.

tempdb Nereye Konmalı?

tempdb’yi elinizdeki en hızlı depolamaya koyun. Her dosya için ayrı disk gerekmez. Microsoft’un önerisi, dosyaları yalnızca disk seviyesinde I/O darboğazı görüyorsanız disklere bölmek ve tempdb ile kullanıcı veritabanları I/O için yarışıyorsa tempdb’yi onların disklerinden ayırmaktır. Deneyimimize göre en sık görülen tempdb olayları gecikmeyle değil alanla ilgilidir: yoğun saatlerde dolan diskler ve bunlara eşlik eden kötü seçilmiş autogrowth ayarları.

tempdb’yi taşımak için dosya yollarını değiştirip servisi yeniden başlatın. Dosyalar başlangıçta yeni konumda oluşturulur; eski dosyaları ardından elle silin:

ALTER DATABASE tempdb MODIFY FILE (NAME = N'tempdev', FILENAME = N'T:\TempDB\tempdb.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = N'templog', FILENAME = N'L:\TempDBLog\templog.ldf');
-- Her ek data dosyası için tekrarlayın, sonra SQL Server servisini yeniden başlatın

Restart’tan önce klasörlerin var olduğundan ve SQL Server servis hesabının onlara yazabildiğinden emin olun. SQL Server başlangıçta tempdb’yi oluşturamazsa servis başlamaz.

tempdb Contention ve Sürümlere Göre Değişenler

Contention, tempdb sayfalarında PAGELATCH_UP ya da PAGELATCH_EX beklemeleri olarak görülür: birçok session’ın aynı anda geçici nesne oluşturup silmesi ve aynı allocation ya da metadata sayfalarında sıraya girmesi. Son sürümlerin her biri bu darboğazın bir kısmını kaldırdı:

SQL Server 2019 ve sonrasında contention sürüyorsa, bunun allocation sayfalarında değil metadata‘da olup olmadığına bakın. Microsoft’un tanılama sorgusu yalnızca session’lar tempdb sistem tablolarında bekliyorsa satır döndürür:

SELECT OBJECT_NAME(dpi.object_id, dpi.database_id) AS system_table_name,
       COUNT(DISTINCT r.session_id)               AS session_count
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.fn_PageResCracker(r.page_resource) AS prc
CROSS APPLY sys.dm_db_page_info(prc.db_id, prc.file_id, prc.page_id, 'LIMITED') AS dpi
WHERE dpi.database_id = 2
  AND dpi.object_id IN (3, 9, 34, 40, 41, 54, 55, 60, 74, 75)
  AND UPPER(r.wait_type) LIKE N'PAGELATCH[_]%'
GROUP BY dpi.object_id, dpi.database_id;

Bu sorgu yük altında düzenli olarak satır döndürüyorsa memory-optimized tempdb metadata yardımcı olabilir. ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON; ve bir restart ile açılır. Microsoft bunu yalnızca metadata contention iş yükünü ciddi şekilde etkiliyorsa öneriyor ve belleğini sınırlamak için bir resource pool’a bağlamayı tavsiye ediyor. Bazı kısıtlamaları da var; örneğin açıkken geçici tablolarda columnstore index oluşturulamaz.

tempdb Alanını Bitmeden İzleyin

Bu sorgu tempdb’yi şu anda neyin kullandığını gösterir:

SELECT SUM(unallocated_extent_page_count)      * 8 / 1024 AS free_space_mb,
       SUM(version_store_reserved_page_count)  * 8 / 1024 AS version_store_mb,
       SUM(internal_object_reserved_page_count)* 8 / 1024 AS internal_objects_mb,
       SUM(user_object_reserved_page_count)    * 8 / 1024 AS user_objects_mb
FROM tempdb.sys.dm_db_file_space_usage;

Sonucu şöyle okuyun:

• Büyük iç nesneler: tempdb’ye taşan sort ve hash’ler. Eksik index’i ya da düşük memory grant’i olan sorgulara ve SORT_IN_TEMPDB kullanan index rebuild’lere bakın. sys.dm_db_task_space_usage ve sys.dm_db_session_space_usage hangi session’ların sorumlu olduğunu gösterir.
• Büyük kullanıcı nesneleri: çoğu zaman raporlama ya da ETL kodundaki büyük geçici tablolar veya table variable’lar.
• Büyüyen version store: genellikle READ_COMMITTED_SNAPSHOT ya da snapshot isolation kullanan bir veritabanında uzun süren bir transaction. O bitene kadar satır versiyonları temizlenemez. sys.dm_tran_version_store_space_usage bunları hangi veritabanının ürettiğini gösterir.

Eşikleri SQL Server uyarılarına dönüştürün; böylece müdahale için hâlâ zaman varken birine haber gider.

tempdb Kontrol Listesi

• Data dosyaları: 8’e kadar mantıksal işlemci sayısı kadar; contention sürerse yalnızca 4’ün katları halinde daha fazla.
• Tüm data dosyaları aynı boyutta ve aynı sabit MB büyümeyle.
• Başlangıç boyutu ölçülmüş en yüksek kullanıma göre; tempdb her restart’tan sonra yeniden büyümesin.
• Servis hesabı için instant file initialization açık.
• Hızlı depolama; I/O için yarışıyorlarsa kullanıcı veritabanlarından ayrı.
• SQL Server 2016 ve sonrasında trace flag 1117 ya da 1118 yok.
• tempdb boş alanı ve disk boş alanı için alarmlar; RCSI ve snapshot kullanan veritabanlarında version store boyutu izleniyor.
• SQL Server 2025’te kontrolden çıkabilecek iş yükleri için tempdb space resource governance değerlendirildi.