SQL Server Transaction Log Doldu (Error 9002): Nedeni Bulma ve Güvenli Çözüm
log_reuse_wait_desc ile logun neden temizlenemediğini bulur ve nedene göre çözer: log yedeği, açık transaction, replika veya replikasyon. Yanlış "SIMPLE'a geç ve shrink et" hatasını önler.
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.
1. Belirti / Symptom
- `Error 9002: The transaction log for database 'X' is full due to 'LOG_BACKUP'` (veya başka neden).
- Yazma işlemleri başarısız; M30 %90 üzeri.
2. Etki / Impact
İlgili veritabanında **yazmalar durur**, okumalar sürer. Uygulama yazma hataları verir.
3. Teşhis / Diagnosis
SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases WHERE name = 'X';
SELECT used_log_space_in_percent, total_log_size_in_bytes/1048576 AS log_mb
FROM sys.dm_db_log_space_usage; -- ilgili veritabanı bağlamında| Değer | Anlamı | Çözüm |
|---|---|---|
| `LOG_BACKUP` | FULL recovery'de log yedeği alınmıyor | Log yedeği alın |
| `ACTIVE_TRANSACTION` | Uzun/açık transaction | Transaction'ı bulun (S49) |
| `AVAILABILITY_REPLICA` | Always On replika geride | Replikayı kontrol edin |
| `REPLICATION` | Log reader agent geride/durmuş | Replikasyon agent'ını düzeltin |
| `DATABASE_MIRRORING` | Mirror geride | Mirror durumunu kontrol edin |
| `CHECKPOINT` | Henüz checkpoint olmamış | `CHECKPOINT;` |
| `NOTHING` | Sorun yok / alan başka nedenle dolu | Disk dolu mu kontrol edin |
4. Müdahale / Response
1. **`LOG_BACKUP` ise (en sık):** Log yedeği alın. Disk için yer gerekiyorsa yedeği başka bir sürücüye alın:
BACKUP LOG [X] TO DISK = N'E:\Yedek\X_log.trn';Yedek sonrası log kullanımı boşalır (dosya boyutu küçülmez, sadece içi boşalır).
2. **`ACTIVE_TRANSACTION` ise:** Transaction'ı bulun ve sonlandırın (rollback uzun sürebilir):
DBCC OPENTRAN('X');
KILL <spid>;3. **`AVAILABILITY_REPLICA` ise:** Replika bağlantısını/erişilebilirliğini düzeltin. Replika çok uzun süre kopuksa log şişer; dayanılmaz hale gelirse replikayı AG'den çıkarmayı değerlendirin.
ALTER DATABASE [X] ADD LOG FILE
(NAME = X_log2, FILENAME = N'F:\Log\X_log2.ldf', SIZE = 8GB, FILEGROWTH = 1GB);6. **Kalıcı çözüm:**
- Log yedek job'ını sık çalıştırın (RPO'ya göre 5-15 dk) ve başarısızlığını izleyin (M33).
- Log dosyasını doğru boyutlayın, sabit MB cinsinden `FILEGROWTH` verin (yüzde değil), VLF sayısını kontrol edin.
- Toplu işleri küçük batch'lere bölün.
5. Doğrulama / Verification
- `log_reuse_wait_desc = NOTHING` ve `used_log_space_in_percent` normal.
- Yazmalar başarılı, uygulama hataları durdu.
- Log yedek zinciri sağlam (`msdb.dbo.backupset` ardışık LSN).
6. Geri Alma / Rollback
- Geçici ek log dosyasını işiniz bitince kaldırın: önce `DBCC SHRINKFILE (X_log2, EMPTYFILE)` sonra `ALTER DATABASE ... REMOVE FILE X_log2`.
- `KILL` ve `SIMPLE` geçişi geri alınamaz (zincir kopar).