Netsis Transaction Log Şişmesi: Çözüm ve Yedekleme Stratejisi

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

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

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ı