SQL Server Transaction Log Full (Error 9002): Find the Cause and Fix Safely
Uses log_reuse_wait_desc to find why the log cannot be truncated and fixes it by cause: log backup, open transaction, replica or replication. Avoids the "switch to SIMPLE and shrink" mistake.
Operational Safety & Risk Notice
This runbook contains operational intervention steps; several are write-impacting (KILL, terminate, DROP, RESIZE). Verify in a staging environment first, and apply sequentially in production with verification.
1. Symptom & Signals
- `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. Business & Technical Impact
İlgili veritabanında **yazmalar durur**, okumalar sürer. Uygulama yazma hataları verir.
3. Diagnosis & Root-Cause Analysis
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. Remediation & Action Plan
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. Verification & Health Checks
- `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. Rollback & Contingency Plan
- 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).