dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #33
sqlserver
CapacitySEV1 · KRİTİK KESİNTİ15-30 dakika / 15-30 minssysadmin / CONTROL SERVER / VIEW SERVER STATE

SQL Server TempDB Doldu: Alanı Kimin Tükettiğini Bulma

TempDB dosyası, version store ve disk doluluğu arasındaki farkı bulur; tüketen oturum veya büyüme sınırına göre güvenli müdahale sırası sunar.

İlişkili Metrik:M34
İlişkili Script:S52S49
#tempdb#space#version-store#autogrowth

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M34 TempDB boş alanı < %10; `tempdb is full`, `Could not allocate space for object ... in database 'tempdb'` gibi hatalar.

- Sort/hash spill, geçici tablo ve row-version kullanan sorgular başarısız olabilir.

2. Etki / Impact

Birden çok veritabanındaki sorgular ve işlemler etkilenir; TempDB instance genelinde paylaşıldığı için sorun tek uygulamayla sınırlı kalmayabilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. TempDB içindeki tahsisleri dosya bazında ayırın (S52; SQL Server 2012+):
sql
SELECT file_id,
       total_page_count * 8 / 1024 AS total_mb,
       unallocated_extent_page_count * 8 / 1024 AS free_mb,
       user_object_reserved_page_count * 8 / 1024 AS user_mb,
       internal_object_reserved_page_count * 8 / 1024 AS internal_mb,
       version_store_reserved_page_count * 8 / 1024 AS version_store_mb
FROM tempdb.sys.dm_db_file_space_usage;
🟢 Salt Okunur2. En çok user/internal obje kullanan oturumları bulun (oturum toplamlarıdır; şu anki aktif isteğe birebir atfedilemeyebilir):
sql
SELECT TOP (20) s.session_id, s.login_name, s.host_name,
       (u.user_objects_alloc_page_count-u.user_objects_dealloc_page_count)*8/1024 AS user_mb,
       (u.internal_objects_alloc_page_count-u.internal_objects_dealloc_page_count)*8/1024 AS internal_mb
FROM sys.dm_db_session_space_usage AS u
JOIN sys.dm_exec_sessions AS s ON s.session_id = u.session_id
WHERE s.is_user_process = 1
ORDER BY (u.user_objects_alloc_page_count-u.user_objects_dealloc_page_count
        +u.internal_objects_alloc_page_count-u.internal_objects_dealloc_page_count) DESC;
🟢 Salt Okunur3. **Version store yüksekse** S49 ile uzun açık transaction'ları ve snapshot/RCSI kullanan uzun okumaları inceleyin. **ADR (Accelerated Database Recovery) açık kullanıcı veritabanlarında** PVS ilgili kullanıcı veritabanında tutulur; tüm sürümleme yükünün TempDB'de olacağını varsaymayın.
🟢 Salt Okunur4. S45 ile TempDB dosyalarının `MAXSIZE`, `FILEGROWTH`, toplam boyut ve bağlı olduğu sürücünün **gerçek boş alanını** kontrol edin. İçeride boş alan varsa fiziki disk alarmı farklı bir dosyadan kaynaklanıyor olabilir.

4. Müdahale / Response

🟡 Geri Alınabilir1. Gereksiz toplu rapor/sort işini sahibiyle koordine ederek durdurun; transaction açık ise geri alma disk alanını hemen serbest bırakmayabilir. `KILL` kararında rollback süresini ve bağımlı iş akışını kontrol edin:
sql
KILL 123;  -- 123: doğrulanmış, güvenle durdurulabilecek session_id
KILL 123 WITH STATUSONLY;
🟡 Geri Alınabilir2. Disk alanı yeterliyse ve mevcut TempDB datafile büyüyemiyorsa, gerçek **mantıksal dosya adını** S45 ile doğruladıktan sonra kapasiteyi artırın:
sql
ALTER DATABASE tempdb MODIFY FILE
  (NAME = N'tempdev', SIZE = 16384MB, FILEGROWTH = 1024MB);

`tempdev` adı örnektir, sisteminizde farklı olabilir. Dosyanın mevcut boyutundan küçük SIZE vermeyin; OS üzerinde yeterli yer ve makul büyüme aralığı şart.

🟡 Geri Alınabilir3. Version store'a neden olan uzun okuma/transaction için uygulama sahibini uyarın, oturumu güvenle kapatın. Temizlik asenkrondur; anlık boşalma beklemeyin.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. **İlk çare olarak SQL Server hizmetini yeniden başlatmayın:** Tüm veritabanlarında kesinti yaratır. `DBCC SHRINKFILE` ile sürekli daraltma ve yeniden büyüme döngüsü oluşturmayın; kullanımdaki TempDB alanını kurtaramaz.

5. **Kalıcı çözüm:** TempDB'yi iş yüküne uygun boyutlandırın; gereksiz spill'leri, uzun snapshot transaction'larını ve sorgu planlarını düzeltin, disk/alan eşiği için büyüme alarmı ekleyin.

5. Doğrulama / Verification

- M34 tekrar güvenli boş alanı gösteriyor ve artan kullanıma rağmen kararlı.

- Önceden başarısız olan sorgu tamamlanıyor; disk alanı ve TempDB version store trendi düzeldi.

6. Geri Alma / Rollback

- `FILEGROWTH` önceki değere alınabilir; dosya boyutunu küçültmek alan kullanımına bağlıdır ve otomatik rollback yoktur.

- `KILL` geri alınamaz; transaction geri sarılır, uygulama gerekirse tekrar dener.

Diğer SQLSERVER Runbook'ları