SQL Server Delayed Durability: Daha Hızlı Commit, Gerçek Veri Kaybı Riski

SQL Server’da bir transaction commit edildiğinde, istemciye “tamamlandı” yanıtı ancak transaction log kaydı diske yazıldıktan sonra döner. Bu bekleme, verinin sunucu çökse bile kaybolmamasını garanti eder; ama log diski yavaşsa ya da uygulama çok sayıda küçük transaction gönderiyorsa, her commit’in bu yazmayı beklemesi performansın darboğazı olur ve WRITELOG beklemeleri tavan yapar.

Delayed durability, SQL Server 2014 ile gelen ve bu bekleyişi atlayan bir seçenektir: commit, log diske yazılmadan önce başarılı döner. Kazanç gerçek olabilir; ama bedeli de gerçektir: sunucu çökerse son commit edilen transaction’lar kaybolabilir. Bu yazıda nasıl çalıştığını, ne zaman kabul edilebilir olduğunu ve önce denenmesi gereken alternatifleri anlatıyoruz.

Nasıl Çalışır?

Delayed durable bir transaction commit edildiğinde log kayıtları önce bellekteki log buffer’da kalır. Buffer diske şu durumlarda yazılır:

• Log buffer dolduğunda.
• Aynı veritabanında tam dayanıklı (fully durable) bir transaction commit edildiğinde.
• sys.sp_flush_log çağrıldığında.
• SQL Server düzgün şekilde kapatıldığında.

Bu arada sunucu beklenmedik şekilde kapanırsa (güç kesintisi, işletim sistemi çökmesi, sürecin sonlandırılması), buffer’daki log kayıtları kaybolur ve uygulamanın “commit edildi” diye bildiği transaction’lar geri gelmez.

Nasıl Açılır?

Ayar veritabanı düzeyinde üç değer alır:

-- DISABLED: varsayılan, tüm commit'ler tam dayanıklı
-- ALLOWED : her transaction kendi seçimini yapabilir
-- FORCED  : tüm commit'ler delayed durable
ALTER DATABASE StagingDB SET DELAYED_DURABILITY = ALLOWED;

-- ALLOWED iken transaction düzeyinde seçim
BEGIN TRAN;
    INSERT INTO dbo.YuklemeLog (Kaynak, Satir) VALUES (N'ERP', 1500);
COMMIT TRAN WITH (DELAYED_DURABILITY = ON);

-- Kritik bir noktada bekleyen log kayıtlarını diske yaz
EXEC sys.sp_flush_log;

Mevcut durumu kontrol etmek için:

SELECT name, delayed_durability_desc
FROM sys.databases
WHERE delayed_durability_desc <> N'DISABLED';

Ne Zaman Kabul Edilebilir?

• Yeniden üretilebilir veriler: Kaynaktan yeniden yüklenebilen staging ve ETL ara tabloları.
• Kaybı tolere edilebilen kayıtlar: Ayrıntılı uygulama logları, telemetri ya da tıklama verileri.
• Toplu yüklemeler: Yarıda kalırsa baştan çalıştırılabilen yükleme işleri.

Kısıtlar: delayed durability, çapraz veritabanı ve dağıtık (distributed) transaction’larda geçerli değildir; bunlar her zaman tam dayanıklıdır. Always On ortamında, primary’nin beklenmedik kapanmasında henüz secondary’ye gönderilmemiş delayed durable transaction’lar kaybolabilir.

Önce Bunları Deneyin

Delayed durability’ye geçmeden önce log yazma darboğazının nedenini bulun:

• Log diskinin gecikmesi: Log yazmaları için birkaç milisaniyenin üzerindeki gecikmeler doğrudan commit süresine yansır. Log dosyasını hızlı ve ayrı bir diske taşımak çoğu zaman sorunu kökten çözer.
• Çok küçük transaction’lar: Döngü içinde satır satır insert ve her satırda commit, binlerce ayrı log yazması demektir. İşlemleri makul büyüklükte gruplara toplayıp tek commit ile yapmak, aynı kazancı veri kaybı riski olmadan sağlar.
• Gereksiz log üretimi: Büyük güncellemelerde değişmeyen kolonları güncellemek ya da gereksiz index’ler log hacmini artırır.

-- Log yazma gecikmesi (ms) ve WRITELOG beklemeleri
SELECT DB_NAME(vfs.database_id) AS database_name,
       vfs.io_stall_write_ms / NULLIF(vfs.num_of_writes, 0) AS avg_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
JOIN sys.master_files AS mf ON mf.database_id = vfs.database_id AND mf.file_id = vfs.file_id
WHERE mf.type_desc = N'LOG'
ORDER BY avg_write_ms DESC;

SELECT wait_type, waiting_tasks_count, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = N'WRITELOG';

Kontrol Listesi

• WRITELOG beklemeleri ve log diski gecikmesi ölçüldü.
• Log dosyası hızlı ve ayrı bir diskte.
• Küçük transaction’lar mümkün olduğunca gruplandı.
• Delayed durability yalnızca kaybı kabul edilebilir verilerde ve iş birimi onayıyla kullanılıyor.
• FORCED mod kritik veritabanlarında kullanılmıyor.