Netsis Transaction Log Şişmesi: SQL Server Log Yönetimi

Kısa cevap: Netsis transaction log (.ldf) dosyası genellikle recovery model FULL olup log backup yapılmadığı için şişer. Çözüm: recovery model’i kontrol edin, FULL ise saatlik BACKUP LOG zinciri kurun, açık transaction’ları DBCC OPENTRAN ile bulun ve log’u yalnızca tek seferlik acil durumda DBCC SHRINKFILE ile küçültün.

Netsis veritabanınızın log dosyası (.ldf) aşırı büyüdü mü? Bu rehberde transaction log’un neden şiştiğini, log shrink yöntemlerini ve doğru yedekleme stratejisini anlatıyoruz.

Transaction Log Nedir?

SQL Server her INSERT, UPDATE, DELETE işlemini log dosyasına kaydeder. Bu log:

Recovery (kurtarma) için kullanılır
Replication için temel oluşturur
Point-in-time restore imkanı sağlar

Log Şişmesinin Sebepleri

1. Yanlış Recovery Model

Recovery model FULL ama log backup yapılmıyor → log dosyası hiç temizlenmez ve büyür.

2. Uzun Süren Transaction

Açık kalmış bir transaction (commit veya rollback yapılmamış) log’un kesilmesini engeller.

3. Replication / Mirroring Sorunu

Log shipping veya replication geride kaldığında log birikir.

4. Toplu İşlem

Yıl sonu kapanışı, toplu fatura aktarımı gibi büyük işlemler log’a yansır.

Çözüm Adımları

1. Recovery Model Kontrolü

SELECT name, recovery_model_desc 
FROM sys.databases WHERE name = "NETSIS_DB";

FULL ise log backup zinciri kurulmalı. SIMPLE ise log otomatik temizlenir.

2. Log Backup (FULL recovery için)

BACKUP LOG [NETSIS_DB] 
TO DISK = "C:\Backup\netsis_log.trn" 
WITH NOFORMAT, NOINIT;

Log backup düzenli yapılmazsa log büyümeye devam eder.

3. Log Shrink

USE [NETSIS_DB];
DBCC SHRINKFILE (NETSIS_DB_log, 500);  -- 500 MB'e küçült

⚠️ Dikkat: Shrink sonrası log fragmente olabilir, performans etkisi yapar. Shrink sadece tek seferlik acil durum içindir.

4. Açık Transaction Tespiti

DBCC OPENTRAN ([NETSIS_DB]);

Açık transaction varsa SPID kaydedilir → kullanıcıyı kibarca kapanmaya yönlendirin.

Doğru Yedekleme Stratejisi

Tip	Sıklık
Full backup	Haftalık (Pazar gece)
Differential	Günlük
Log backup	Saatlik (FULL recovery için)

SIMPLE vs FULL Recovery Model

SIMPLE: Log otomatik temizlenir, point-in-time restore yok

FULL: Log backup ile saatlik restore mümkün, daha fazla yönetim ister

Üretim ortamında FULL önerilir.

Önleyici Tedbirler

✅ Log dosyası boyut takibi (uyarı 80% doluluk)
✅ Log backup zinciri kurulumu
✅ Açık transaction monitör
✅ Aylık DBCC CHECKDB
✅ Log dosyası ayrı diskte tutulmalı

İlgili Yazılar ve Hizmetler

Sıkça Sorulan Sorular

Transaction log dosyasını silebilir miyim?

Hayır, .ldf log dosyası asla manuel olarak silinmemelidir; veritabanı bozulur ve açılmaz hale gelir. Doğru yöntem log backup almak veya SIMPLE recovery model kullanmaktır. Acil durumda sadece DBCC SHRINKFILE ile boyutu küçültebilirsiniz, dosyanın kendisini değil.

Recovery model’i FULL’den SIMPLE’a çevirsem log şişmesi durur mu?

Evet, SIMPLE recovery model’de log her checkpoint sonrası otomatik temizlenir ve şişmez. Ancak SIMPLE’da point-in-time (anlık) restore imkanı kaybolur; yalnızca en son full/differential yedeğe dönebilirsiniz. Üretim ortamında veri kaybını minimize etmek için FULL + saatlik log backup önerilir.

Log shrink işlemi tehlikeli mi, ne sıklıkta yapmalıyım?

Shrink rutin bir bakım değildir; sadece tek seferlik acil durumlar içindir. Sık shrink, dosya yeniden büyürken fiziksel fragmentasyona ve performans düşüşüne yol açar. Kalıcı çözüm düzenli log backup zinciridir. Düzenli bakım için Netsis bakım anlaşması değerlendirilebilir.

Log backup’ı ne kadar sıklıkta almalıyım?

FULL recovery model kullanan üretim ortamlarında log backup en az saatlik alınmalıdır; yoğun işlem yapan sistemlerde 15-30 dakikalık aralık daha uygundur. Yedek sıklığı, kabul edebileceğiniz maksimum veri kaybı süresini (RPO) belirler.