1. Başlangıç

Tempdb, SQL Server engine’in nefes aldığı yer. Sort, hash join, table variable, temp table, snapshot version store, RCSI version store, internal worktable, hepsi tempdb’de. Bir SQL Server instance’ında tempdb’nin durumu, çoğu zaman instance’ın genel sağlığını anlatır. Yorgun bir tempdb, bütün instance’ta yavaşlık demektir.

Bu hafta tempdb’yi iki tarafından ele alacağız: klasik tarafından (allocation contention, GAM/SGAM/PFS latch’leri, dosya planlama) ve yeni 2025 tarafından (Linux’ta tmpfs ile RAM-backed tempdb, tempdb space resource governance, ADR for tempdb). Dört workshop’la yeni feature’ları gerçek senaryoda göstereceğiz.

Yıllar içinde tempdb darboğazını çözmek DBA olarak en sık yaptığım işlerden biri. Çoğu zaman semptom genel yavaşlık, gerçek sebep tempdb’de. Bu yazıyı okuyunca tempdb’nin hangi noktada darboğaz olduğunu, hangi metric’lerle ölçtüğümüzü, ve 2025 yenilikleriyle nasıl çözeceğimizi netleştirmek istiyorum.

2. Tempdb Nedir, Ne iş Yapar?

Tempdb her instance restart’ında sıfırdan oluşur. Bu yüzden recovery model’i SIMPLE’dır, full backup alınmaz, hassas veri saklamaz. Ama yine de SQL Server’ın en yoğun çalışan database’i.

tempdb’nin ev sahipliği yaptığı nesneler ve onların kaynak tüketimi

Beş ana iş yükü kategorisi var.

1 – User-created temp objects: #temp_table, @table_variable, kullanıcı sorgularında ad-hoc kullanılan tüm geçici yapılar.

2 – Internal worktables: query optimizer’ın sort, hash, spool, lazy spool için kullandığı yapılar.

3 – Snapshot version store: SNAPSHOT isolation aktif transaction’ların eski satır versiyonları.

4 – RCSI version store: READ COMMITTED SNAPSHOT için aynı şey.

5 – Online index build version store: online rebuild operasyonları sırasında eski/yeni satırları tutar.

Bu kategorilerin her biri farklı pattern’de yük üretir. Sort/hash büyük geçici alan ister; version store’lar transaction süresince büyür; #temp_table’lar genelde kısa ömlürlüdür ama allocation tarafında sıkıntı yaratır. Yani ‘tempdb’yi tune et’ demek, hangi kategorinin yük yarattığını teşhis etmekle başlar.

3. Klasik Darboğaz Allocation Contention

Tempdb’nin en bilinen sorunu allocation contention. Sebebi şu: SQL Server yeni bir extent (8 page = 64 KB) ihtiyacı olduğunda GAM (Global Allocation Map), SGAM (Shared GAM) veya PFS (Page Free Space) sayfalarına başvurur. Bu sayfalar üzerinde latch alınır; binlerce eş zamanlı transaction aynı sayfaya saldırırsa PAGELATCH_UP wait’leri ekran karartır.

Allocation contention: çok sayıda session aynı GAM/SGAM/PFS sayfasında latch sırasına girer.

Klasik çözüm tempdb’yi birden çok dosyaya bölmek, her dosya kendi GAM/SGAM/PFS set’ine sahip olur, contention dağılır. Microsoft 2016’dan beri instance kurulumunda bunu otomatik yapıyor; CPU sayısının min(8, NUMA-aware) kadarı kadar dosya kuruyor.

İki eski trace flag, 1117 (her dosyaya eşit autogrowth) ve 1118 (mixed extent allocation kapatma) SQL Server 2016+ otomatik olarak tempdb için etkin durumda. Yani modern instance’larınızda bu trace flag’leri açmanıza gerek yok; engine zaten doğru davranıyor.

tempdb dosya yapılandırmanızı kontrol etmek için:

-- tempdb dosyalari
USE tempdb;
SELECT
    file_id,
    name,
    type_desc,
    physical_name,
    size * 8 / 1024 AS size_mb,
    growth,
    is_percent_growth,
    max_size
FROM sys.database_files
ORDER BY file_id;
-- Aktif tempdb session yuku
SELECT TOP (20)
    session_id,
    database_id,
    user_objects_alloc_page_count,
    internal_objects_alloc_page_count
FROM sys.dm_db_session_space_usage
ORDER BY (user_objects_alloc_page_count
          + internal_objects_alloc_page_count) DESC;

4. Memory-Optimized TempDB Metadata

SQL Server 2019’dan beri var ama hâlâ az kullanılan bir feature: Memory-Optimized TempDB Metadata. tempdb’de oluşturulan #temp_table’ların metadata bilgilerini (sys.tables, sys.columns, vs.) memory-optimized olarak saklamayı sağlıyor. Bu, yüksek-frekansta temp table create eden workload’larda ciddi bir kazanç sağlıyor.

Açmak için tek komut yetiyor, restart gerektiriyor:

-- Memory-Optimized TempDB Metadata
ALTER SERVER CONFIGURATION
    SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON;
GO
-- Restart sonrasi durumu kontrol et
SELECT SERVERPROPERTY('IsTempdbMetadataMemoryOptimized')
    AS is_memopt_tempdb_metadata;
-- 1 dönerse aktif

Production’da açmadan önce dikkat: memory pressure yaratabilir. Resource pool ile binding yaparak limit koymak best practice. Test ortamınızda memory tüketimini sys.dm_db_resource_stats ile gözlemleyin.

-- Resource pool olustur, tempdb metadata'yi binding et
CREATE RESOURCE POOL tempdb_metadata_pool
    WITH (MAX_MEMORY_PERCENT = 20);
ALTER RESOURCE GOVERNOR RECONFIGURE;
ALTER SERVER CONFIGURATION
    SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON
    (RESOURCE_POOL = 'tempdb_metadata_pool');
-- Restart gerekli

5. SQL Server 2025 Tempdb on tmpfs (Linux)

Linux dünyasında en heyecan verici tempdb yeniliği bu. tmpfs, Linux’un RAM-backed filesystem’i. SQL Server 2025’te tempdb dosyalarınızı tmpfs üzerinde tutabiliyorsunuz, yani disk yerine doğrudan RAM’e yazıyor.

Hız farkı dramatik. tempdb’ye sürekli sort/hash spill eden bir workload’da 10-50x hız kazanımı sıradan. Karşılığında: RAM yiyor (tipik tempdb büyüklüğü kadar), restart’ta tempdb sıfırdan inşa edilir (zaten öyle), persistent değil, ki tempdb’nin doğası bu.

Tempdb on disk vs tmpfs: 100K row sort spill senaryosu, elapsed ve disk I/O karşılaştırması.

Container deployment için en hızlı kurulum:

# Docker — tempdb'yi tmpfs'te tut
docker run \
  -e ACCEPT_EULA=Y \
  -e MSSQL_SA_PASSWORD=<password> \
  --tmpfs /var/opt/mssql/tempdb:uid=10001,gid=10001,size=4G \
  -p 1433:1433 \
  --name sql_tmpfs \
  -d mcr.microsoft.com/mssql/server:2025-latest

Container ayağa kalktıktan sonra tempdb dosyalarını yeni mount’a taşımak gerek:

-- tempdb dosya yolunu degistir
ALTER DATABASE tempdb
    MODIFY FILE (NAME = 'tempdev',
                 FILENAME = '/var/opt/mssql/tempdb/tempdb.mdf');
ALTER DATABASE tempdb
    MODIFY FILE (NAME = 'templog',
                 FILENAME = '/var/opt/mssql/tempdb/templog.ldf');
-- Container restart gerekli
-- docker restart sql_tmpfs

Bare-metal Linux’ta tmpfs mount’unu /etc/fstab’a kalıcı ekliyorsunuz, sonra yine ALTER DATABASE ile dosyaları taşıyorsunuz. Hot-resize de mümkün, tmpfs boyutunu çalışırken artırabiliyorsunuz:

# tmpfs'in boyutunu canli artir (4GB → 6GB)
mount -o remount,size=6G /var/opt/mssql/tempdb

Önemli sınır: bu config sadece tempdb için supported. User database’leri tmpfs üzerine koyamazsınız (development senaryoları hariç). Microsoft restart kaybı riskini önlemek için bu sınırı koymuş; tempdb zaten ephemeral olduğu için tmpfs ile uyumu doğal.

6. SQL Server 2025 Tempdb Space Resource Governance

Eski klasik problem: bir runaway sorgu tempdb’yi şişirip diğer tüm session’ları etkiliyor. SELECT INTO #huge_table FROM cross_join_disaster gibi bir hata, 1 TB tempdb dosyası yaratıp instance’ı dize getirebilir. Resource Governor tempdb için artık bu sorunun çözümü.

Tempdb space resource governance ile workload group bazında tempdb tüketimini limitleyebiliyorsunuz. Limit aşılırsa session’ın query’si abort edilir, diğer session’lar etkilenmez.

Resource Governor ile tempdb space kontrolü: workload group’lar kendi quota’larıyla sınırlı kalır

-- Resource pool + workload group olustur
CREATE RESOURCE POOL pool_reporting WITH (MAX_MEMORY_PERCENT = 50);
CREATE WORKLOAD GROUP wg_reporting USING pool_reporting;
-- tempdb space limit (sabit MB)
ALTER WORKLOAD GROUP wg_reporting
    WITH (GROUP_MAX_TEMPDB_DATA_MB = 10240);  -- 10 GB
-- Veya yuzde
ALTER WORKLOAD GROUP wg_reporting
    WITH (GROUP_MAX_TEMPDB_DATA_PERCENT = 25);
ALTER RESOURCE GOVERNOR RECONFIGURE;

Limit izlemesi için DMV’ler genişledi:

SELECT
    name,
    tempdb_data_space_kb,
    peak_tempdb_data_space_kb,
    total_tempdb_data_limit_violation_count
FROM sys.dm_resource_governor_workload_groups
WHERE name IN ('default', 'wg_reporting');

total_tempdb_data_limit_violation_count, ne kadar query’nin abort edildiğini gösterir. Sıfır değilse limit’inizi yeniden değerlendirin, workload büyüklüğüne mi yetmiyor, yoksa runaway query mi var araştırın.

7. SQL Server 2025 ADR Tempdb

Accelerated Database Recovery (ADR), SQL Server 2019’dan beri var. Recovery süresini ciddi azaltıyor, log truncation’ı tempo’da tutuyor. SQL Server 2025’te ADR artık tempdb’deki transaction’lara da uygulanıyor.

Önceden tempdb’de (özellikle temp table kullanan) uzun transaction’lar rollback alındığında tempdb log büyür, recovery uzayabilirdi. Yeni davranışta tempdb’deki transaction’lar da Persistent Version Store benzeri yapıya yararlanıyor.

Ayrı bir konfigürasyon gerektirmiyor, engine otomatik kullanıyor. Ama etkisini görmek için tempdb’deki transaction’larınızı izlemeniz gerekiyor:

-- Aktif tempdb transactionlari
SELECT TOP (20)
    s.session_id,
    DB_NAME(s.database_id) AS db_name,
    DATEDIFF(SECOND, s.last_request_start_time, GETDATE())
        AS active_seconds,
    su.user_objects_alloc_page_count
        + su.internal_objects_alloc_page_count AS pages_used
FROM sys.dm_exec_sessions s
JOIN sys.dm_db_session_space_usage su
    ON s.session_id = su.session_id
WHERE s.is_user_process = 1
ORDER BY pages_used DESC;

8. Workshop 1 Allocation Contention’ı Reprodüce Etmek

Klasik darboğazı kendi gözünüzle görmek için 50 paralel session’la #temp_table üretip wait stat’lara bakacağız. Test ortamında, production’da değil!

-- Once instance'in tempdb dosya sayisini kontrol et
SELECT COUNT(*) AS file_count
FROM tempdb.sys.database_files
WHERE type = 0;  -- 0 = data file
-- Eger 1 dosya varsa contention'i gormek kolay olur (test amacli)
-- 8+ dosya varsa contention zor olusur (zaten dogru kurulu)
-- Yuk uretici stored proc
CREATE OR ALTER PROCEDURE dbo.tempdb_load_test
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @i INT = 0;
    WHILE @i < 100
    BEGIN
        CREATE TABLE #t (id INT, val NVARCHAR(100));
        INSERT INTO #t (id, val)
        SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
                          REPLICATE('x', 100)
        FROM sys.all_columns;
        DROP TABLE #t;
        SET @i = @i + 1;
    END
END
GO
-- Bunu 50 paralel SSMS sekmesinde calistir
EXEC dbo.tempdb_load_test;
-- Wait stats — paralel calisirken baska session'da
SELECT TOP (10)
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'PAGELATCH%'
   OR wait_type LIKE 'PAGEIOLATCH%'
ORDER BY wait_time_ms DESC;
-- Aktif PAGELATCH bekleyen session'lar
SELECT
    session_id,
    wait_type,
    wait_resource,
    blocking_session_id
FROM sys.dm_exec_requests
WHERE wait_type LIKE 'PAGELATCH%';

Single-file tempdb’de PAGELATCH_UP wait’lerini PFS (page 1), GAM (page 2), SGAM (page 3) sayfalarında göreceksiniz, wait_resource ‘2:1:1’, ‘2:1:2’, ‘2:1:3’ formatında. Multi-file tempdb’ye geçince bu wait’ler dağılır, çoğu kaybolur.

Çözüm: tempdb dosya sayısını CPU sayısının min(8, NUMA-aware bölünmüş) kadarı yapmak. SQL Server 2016+ install’larda bu zaten otomatik. Eski instance’larda manuel çoğaltmak gerek:

-- Ek tempdb data file ekle (her birinin baslangic boyutu ayni olmali)
ALTER DATABASE tempdb
    ADD FILE (NAME = 'tempdev2',
              FILENAME = 'C:\TempDB\tempdb2.ndf',
              SIZE = 1024MB, FILEGROWTH = 256MB);
-- Ayni sekilde tempdev3, tempdev4, ...

9. Workshop 2 Linux’ta tempdb on tmpfs Performansı

tmpfs ile RAM-backed tempdb’nin gerçek performans etkisini ölçeceğiz. Tipik bir spill-prone sort sorgusu üzerinde.

-- Once buyuk bir sort yaratacak senaryo kur
CREATE TABLE dbo.SortBench
(
    id INT IDENTITY PRIMARY KEY,
    val NVARCHAR(200),
    grp NVARCHAR(50)
);
INSERT INTO dbo.SortBench (val, grp)
SELECT TOP (500000)
    REPLICATE(NEWID(), 6),
    'GRP_' + CAST(ABS(CHECKSUM(NEWID())) % 10 AS NVARCHAR)
FROM sys.all_columns a CROSS JOIN sys.all_columns b;
-- Disk-bazli tempdb (varsayilan) ile sort ve aggregate
SET STATISTICS TIME, IO ON;
SELECT grp, COUNT(*) AS cnt, MAX(val) AS max_val
FROM dbo.SortBench
GROUP BY grp
ORDER BY cnt DESC
OPTION (MAXDOP 4);
-- Plan'da Hash Match veya Sort spill'i varsa tempdb yuke sokuldu demektir

Test sonuçlarım (4 GB tmpfs vs disk üzerinde XFS): disk-bazlı 6.4 saniye, tmpfs üzerinde 1.8 saniye. 3.5x hız farkı. Bu sorgu spill yapmıyorsa fark az olur, tmpfs’in asıl kazanımı tempdb’ye gerçekten I/O yapan workload’larda.

tmpfs için sizing kararı kritik: tempdb’nin pik kullanımını ölçüp tmpfs boyutunu ona göre belirleyin. Aşımı durumunda ‘No space left on device’ hatası alırsınız ve query fail eder. Hot-resize (mount -o remount,size=…) ile çalışma anında büyütebilirsiniz, ama plan A bu olmasın.

10. Workshop 3 Resource Governor ile Runaway Query Koruması

Bir test database’i kuralım, içinde mahsus runaway query üretelim. Resource Governor olmadan ve sonra olduğunda davranışı karşılaştıralım.

-- Resource Governor'ı acma
ALTER RESOURCE GOVERNOR RECONFIGURE;
-- Bu hesap 'reporting' uygulamadan gelen query'leri tasiyor
CREATE LOGIN reporting_user
    WITH PASSWORD = '<strong-password>';
-- Classifier function — login'e gore wg secimi
CREATE OR ALTER FUNCTION dbo.ClassifyByLogin()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @wg SYSNAME;
    IF SUSER_NAME() = N'reporting_user'
        SET @wg = N'wg_reporting';
    ELSE
        SET @wg = N'default';
    RETURN @wg;
END
GO
ALTER RESOURCE GOVERNOR
    WITH (CLASSIFIER_FUNCTION = dbo.ClassifyByLogin);
-- Workload group'a tempdb limit
ALTER WORKLOAD GROUP wg_reporting
    WITH (GROUP_MAX_TEMPDB_DATA_MB = 1024);  -- 1 GB
ALTER RESOURCE GOVERNOR RECONFIGURE;
-- Runaway query'yi reporting_user olarak calistir
-- (SSMS'te o login ile baglan)
SELECT *
INTO #huge_runaway
FROM Sales.SalesOrderHeader a
CROSS JOIN Sales.SalesOrderHeader b;
-- 1 GB asilirsa: query abort, error 12321 veya benzeri
-- Diger session'lar etkilenmez

Limit aşıldığında engine sadece o session’ı durdurur, error mesajıyla. Diğer tempdb kullanıcıları (default workload group’taki) çalışmaya devam eder. Production’da rapor uygulamasını kendi workload group’una koyup limit vermek, instance genelinde tempdb stabilitesini garantiliyor.

Limit ihlalini izlemek için:

SELECT
    name,
    tempdb_data_space_kb / 1024 AS current_mb,
    peak_tempdb_data_space_kb / 1024 AS peak_mb,
    group_max_tempdb_data_mb AS limit_mb,
    total_tempdb_data_limit_violation_count AS violations
FROM sys.dm_resource_governor_workload_groups
WHERE name IN ('default', 'wg_reporting');

11. Workshop 4 ADR for Tempdb Etkisini Gözle

ADR’nin tempdb tarafına geldiğini ölçmek için klasik long-running transaction + rollback senaryosunu kuralım.

-- Senaryoyu kur
CREATE TABLE #big_temp (id INT, val NVARCHAR(MAX));
BEGIN TRANSACTION;
INSERT INTO #big_temp (id, val)
SELECT TOP (500000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
                    REPLICATE('A', 5000)
FROM sys.all_columns a CROSS JOIN sys.all_columns b;
-- 5GB+ tempdb log yazildi
-- Rollback at
ROLLBACK TRANSACTION;

ADR for tempdb öncesinde bu rollback dakikalarca sürebiliyordu, çünkü her satır log’dan geri okunup ‘undo’ olmak zorundaydı. Yeni davranışta engine Persistent Version Store benzeri yapıyı tempdb için de kullanıyor, rollback neredeyse anında dönüyor (logical undo).

Ölçüm için sys.dm_tran_persistent_version_store_stats analoğu hâlâ tempdb için tam exposed değil; ama wait stats’a bakarak fark ölçülebilir. WRITELOG ve LOGBUFFER wait’leri tempdb için ciddi düşmüş olmalı.

Bu yenilik ‘aktif et’ demek istiyor değil, engine otomatik kullanıyor. Sizin tarafında, uzun süren tempdb transaction’larından kaçınmak hâlâ best practice; ama yanlışlıkla bir tane çalışırsa rollback etkisi minimum.

12. tempdb İzleme Günlük Dashboard

tempdb’yi günlük izlemek için aşağıdaki sorgular pratik. Bunları SQL Agent üzerinden 5 dakikada bir çalıştırıp dashboard tablosuna basıyorum.

-- 1. tempdb space kullanim breakdown
SELECT
    SUM(unallocated_extent_page_count) * 8 / 1024 AS free_mb,
    SUM(version_store_reserved_page_count) * 8 / 1024 AS version_store_mb,
    SUM(user_object_reserved_page_count) * 8 / 1024 AS user_obj_mb,
    SUM(internal_object_reserved_page_count) * 8 / 1024 AS internal_obj_mb,
    SUM(mixed_extent_page_count) * 8 / 1024 AS mixed_mb
FROM tempdb.sys.dm_db_file_space_usage;
-- 2. tempdb'yi en cok kullanan top 10 session
SELECT TOP (10)
    s.session_id,
    s.login_name,
    s.host_name,
    s.program_name,
    su.user_objects_alloc_page_count * 8 / 1024 AS user_mb,
    su.internal_objects_alloc_page_count * 8 / 1024 AS internal_mb
FROM sys.dm_db_session_space_usage su
JOIN sys.dm_exec_sessions s
    ON su.session_id = s.session_id
WHERE su.user_objects_alloc_page_count
    + su.internal_objects_alloc_page_count > 0
ORDER BY user_mb + internal_mb DESC;
-- 3. tempdb wait stats
SELECT TOP (10)
    wait_type,
    waiting_tasks_count,
    wait_time_ms / 1000.0 AS wait_seconds
FROM sys.dm_os_wait_stats
WHERE wait_type IN ('PAGELATCH_UP', 'PAGEIOLATCH_SH',
                    'PAGEIOLATCH_EX', 'PFS', 'WRITELOG')
ORDER BY wait_time_ms DESC;

Bu üç sorgu çoğu tempdb derdini ekrana getirir. version_store_mb sürekli artıyorsa zombie transaction var; PAGELATCH_UP yüksekse contention var; WRITELOG yüksekse log dosyası darboğaz.

13. Sınırlar ve Uyarılar

• tempdb tmpfs üzerinde sadece Linux’ta destekleniyor. Windows tarafında benzer bir feature yok, RAM disk üçüncü parti çözümler unsupported.
• tmpfs boyutu RAM’den geliyor, host’ta yeterli RAM olmadan kurmayın, OS swapping başlar.
• Resource Governor ile tempdb space limit, MAXSIZE’ı bypassla, workload group’tan abort gelirse session’in transaction’i rollback olur.
• ADR for tempdb otomatik açık ama disabled etmenin yolu yok (zaten istemiyorsunuz).
• Memory-Optimized TempDB Metadata, çok-eşzamanlı temp table create eden workload’larda fark yaratır; tek kullanıcılı senaryoda kazanç sıfır.
• tempdb’de full text catalog desteklenmiyor.
• Optimized Locking tempdb’de aktif değil, dah önce makalesini yazmıştık belirtmiştik.
• tempdb dosya sayısını runtime’da değiştirmek instance restart gerektirir; planlı bakım penceresi şart.

14. Bölüm Sonu

tempdb optimizasyonu, instance genelinde performans etkisi en yüksek alanlardan biri. Klasik darboğazlar (allocation contention, dosya sayısı, memory-optimized metadata) hâlâ geçerli; SQL Server 2025 üzerine üç yeni katman ekledi: tmpfs (Linux), space resource governance ve ADR for tempdb.

Workshop 1-4’ü kendi laboratuvarında çalıştırmanı tavsiye ederim. Özellikle Workshop 2’deki tmpfs farkı, eğer Linux’ta SQL Server kullanıyorsan kafa açıcı bir deneyim. Container deployment’larda neredeyse zorunlu hale geldi bence, RAM bol ve ucuz, tempdb’yi disk’e bağlamak için artık iyi bir gerekçe yok.

Sonraki yazıda Güvenlik Sıfırdan serisinin ilk parçası olan SQL Injection’a geçeceğiz. Klasik atak vektörleri, korunma katmanları ve SQL Server 2025’te gelen Regular Expression fonksiyonlarıyla input validation üzerine konuşacağız.

tempdb deneyimlerinizi yorumlara yazın. Özellikle tmpfs’e geçenlerin before/after metric’leri, Resource Governor ile kapanan runaway query vakaları, bu deneyimler sonraki yazılara güzel vaka örnekleri olur.