SQL Server Simple Recovery Model: Ne Zaman Kullanılmalı, Ne Zaman Kullanılmamalı?

Bir SQL Server veritabanının felaket anında ne kadar veri kaybedeceğini çoğu zaman tek bir ayar belirler: recovery model. Bu ayar transaction log’un nasıl yönetileceğini, log backup alınıp alınamayacağını ve hangi restore senaryolarının mümkün olduğunu doğrudan etkiler. Simple recovery model ise bu seçeneklerin en kolay yönetileni, ama aynı zamanda en az koruma sağlayanıdır.

Bu yazıda SQL Server’da simple recovery model’in tam olarak ne yaptığını, full recovery model’den farkını, hangi durumlarda doğru, hangi durumlarda riskli bir tercih olduğunu, recovery model’in nasıl kontrol edilip değiştirileceğini ve geçiş sırasında log zincirini kırmamak için nelere dikkat edilmesi gerektiğini anlatıyoruz.

Simple Recovery Model Nedir?

SQL Server’da her veritabanının bir recovery model’i vardır ve üç seçenek bulunur: simple, full ve bulk-logged. Simple recovery model’de:

• Transaction log backup alınamaz. Yalnızca full ve differential backup alabilirsiniz.
• Log alanı otomatik olarak geri kazanılır. Her checkpoint sonrasında log’un artık ihtiyaç duyulmayan kısmı yeniden kullanılabilir hale gelir (log truncation). Log backup almanız gerekmez.
• Yalnızca bir backup’ın sonuna dönebilirsiniz. Son full veya differential backup’tan sonra yapılan tüm değişiklikler, bir felaket durumunda kaybolur ve yeniden yapılması gerekir.

Önemli bir not: Microsoft’a göre SQL Server Enterprise ve Standard edition’larda yeni veritabanları varsayılan olarak full, Express edition’da ise simple recovery model ile oluşturulur. Yeni veritabanları bu ayarı model veritabanından devralır. Yani Express’ten Standard’a geçen bir uygulamanın veritabanları, kimse fark etmeden simple modda kalmış olabilir.

Simple, Full ve Bulk-Logged Recovery Model Karşılaştırması

Bulk-logged model, büyük bulk import veya index rebuild işlemleri sırasında log büyümesini sınırlamak için full model’e geçici bir alternatif olarak kullanılır. Kalıcı bir tercih olarak nadiren doğrudur.

Simple Recovery Model Ne Zaman Doğru Tercihtir?

Simple recovery model kötü bir ayar değildir, yalnızca doğru yerde kullanılması gerekir. Şu durumlarda makul bir seçimdir:

• Kolayca yeniden oluşturulabilen veriler: her gece kaynaktan yeniden yüklenen staging veritabanları, ETL ara tabloları, raporlama kopyaları.
• Geliştirme ve test ortamları: veri kaybının iş açısından sonucu olmayan, production kopyası veritabanları.
• Salt okunur veya çok seyrek değişen veritabanları: değişiklikler yalnızca planlı bir yükleme sırasında oluyorsa, yüklemeden hemen sonra alınan bir full backup yeterli koruma sağlar.
• Kabul edilen veri kaybı penceresinin backup sıklığından uzun olduğu sistemler: iş birimi “son 24 saatlik veriyi kaybetmeyi kabul ediyoruz” diyorsa ve günlük full backup alınıyorsa simple model bu hedefi karşılar.

Simple Recovery Model Ne Zaman Risklidir?

Şu durumlardan biri geçerliyse veritabanınız full recovery model’de olmalıdır:

• Kaybedilemeyecek işlemsel veri: sipariş, ödeme, muhasebe, ERP, CRM gibi gün içinde sürekli yazılan sistemler. Gece alınan bir full backup ile simple model, öğleden sonra yaşanan bir disk arızasında o güne ait tüm işlemlerin kaybolması demektir.
• Kullanıcı hatasına karşı koruma ihtiyacı: filtresiz bir DELETE veya UPDATE sonrasında hatadan bir dakika öncesine dönebilmek için point-in-time restore gerekir. Simple modda bu mümkün değildir.
• Yüksek erişilebilirlik ve felaket kurtarma: Always On availability groups, database mirroring ve log shipping simple recovery model ile çalışmaz.
• Belirli RPO hedefleri olan sözleşmeler: müşteriye “en fazla 15 dakikalık veri kaybı” taahhüt ediyorsanız, bunu yalnızca full recovery model ve 15 dakikada bir alınan log backup’lar karşılayabilir.

Recovery Model Nasıl Kontrol Edilir?

Tüm veritabanlarının recovery model’ini ve log’un neden temizlenemediğini tek sorguda görebilirsiniz:

SELECT name,
       recovery_model_desc,
       log_reuse_wait_desc
FROM sys.databases
ORDER BY recovery_model_desc, name;

SSMS’te ise veritabanına sağ tıklayıp Properties → Options sayfasındaki Recovery model alanına bakabilirsiniz.

Full modda olup log backup’ı alınmayan veritabanları

Tersi de bir o kadar yaygın bir sorundur: veritabanı full modda ama hiç log backup alınmıyor. Bu durumda log sürekli büyür ve sonunda diski doldurur. Aşağıdaki sorgu son log backup tarihini gösterir:

SELECT d.name,
       d.recovery_model_desc,
       MAX(b.backup_finish_date) AS last_log_backup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
       ON b.database_name = d.name
      AND b.type = 'L'
WHERE d.recovery_model_desc IN (N'FULL', N'BULK_LOGGED')
  AND d.database_id > 4
GROUP BY d.name, d.recovery_model_desc
ORDER BY last_log_backup;

last_log_backup sütunu boşsa veya çok eskiyse, ya log backup job’ı kurulmalı ya da veritabanının gerçekten full modda olması gerekip gerekmediği sorgulanmalıdır. Transaction log’un büyümesiyle ilgili ayrıntıları Transaction Log’unuz Çok Mu Büyük? yazımızda bulabilirsiniz.

Recovery Model Nasıl Değiştirilir?

Recovery model, veritabanı üzerinde ALTER yetkisi olan bir kullanıcı tarafından istenildiği an değiştirilebilir:

USE [master];

-- Simple'a geçiş
ALTER DATABASE [StagingDB] SET RECOVERY SIMPLE;

-- Full'a geçiş
ALTER DATABASE [SalesDB] SET RECOVERY FULL;

Komut anında çalışır, ancak geçişin backup zincirine etkisi vardır. Microsoft’un bu konudaki önerileri nettir. Ayrıca değişiklik sırasında veritabanının plan cache’i temizlenir, bu yüzden yoğun saatlerde yapmamak daha iyidir.

Full’dan simple’a geçerken

1. Geçişten önce bir log backup alın. Böylece o ana kadarki işlemler korunmuş olur.
2. Geçişle birlikte log zinciri kırılır. Geçiş anından sonrası için point-in-time restore artık mümkün değildir.
3. Zamanlanmış log backup job’larını durdurun; aksi halde hata vermeye başlarlar.
4. Düzenli full (ve gerekirse differential) backup’ların planlı olduğundan emin olun. Artık tek korumanız bunlardır.

Simple’dan full’a geçerken

1. Geçişten hemen sonra bir full veya differential backup alın. Microsoft’a göre full recovery model, ilk data backup alınana kadar fiilen devreye girmez; o ana kadar log, simple modda olduğu gibi checkpoint’te temizlenmeye devam eder.
2. Düzenli log backup’ları zamanlayın ve restore planınızı güncelleyin. Log backup alınmazsa log, disk dolana kadar büyür.

-- Simple'dan full'a güvenli geçiş
ALTER DATABASE [SalesDB] SET RECOVERY FULL;

-- Log zincirini başlatmak için hemen bir full backup
BACKUP DATABASE [SalesDB]
TO DISK = N'E:\Backup\SalesDB_FULL_after_switch.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;

-- Ardından düzenli log backup'lar (ör. her 15 dakikada bir, bir Agent job ile)
BACKUP LOG [SalesDB]
TO DISK = N'E:\Backup\SalesDB_LOG.trn'
WITH COMPRESSION, CHECKSUM;

Simple Modda Transaction Log Neden Hâlâ Büyür?

Simple recovery model’in “log’u yönetmenize gerek yok” vaadi her zaman geçerli değildir. Log checkpoint’te temizlenir, ancak hâlâ ihtiyaç duyulan log kayıtları silinemez. En sık nedenler:

• Uzun süren transaction’lar: açık kalan tek bir transaction, başladığı noktadan sonraki tüm log’un korunmasına yol açar. Microsoft bunun simple model dahil tüm recovery model’lerde log truncation’ı engellediğini belirtir. Gece çalışan büyük bir DELETE veya index bakımı tipik örneklerdir.
• Devam eden bir data backup veya restore: backup sürerken log truncation ertelenir.
• Tek bir transaction içinde yapılan büyük işlemler: milyonlarca satırı tek seferde güncellemek, log’un o işlem bitene kadar büyümesine neden olur. Bu işlemleri küçük parçalara (batch) bölmek, simple modda log boyutunu kontrol altında tutmanın en etkili yoludur.

Log’un neden temizlenemediğini sys.databases içindeki log_reuse_wait_desc sütunu söyler. ACTIVE_TRANSACTION görüyorsanız açık transaction’ı bulmak için şu sorguyu kullanabilirsiniz:

SELECT s.session_id,
       s.login_name,
       s.host_name,
       dt.database_transaction_begin_time,
       DATEDIFF(MINUTE, dt.database_transaction_begin_time, SYSDATETIME()) AS open_minutes,
       dt.database_transaction_log_bytes_used / 1048576 AS log_used_mb
FROM sys.dm_tran_database_transactions AS dt
JOIN sys.dm_tran_session_transactions AS st ON dt.transaction_id = st.transaction_id
JOIN sys.dm_exec_sessions AS s ON st.session_id = s.session_id
WHERE dt.database_id = DB_ID(N'StagingDB')   -- kendi veritabanınızla değiştirin
ORDER BY dt.database_transaction_begin_time;

Simple model’in bir avantajı da şudur: BULK INSERT, SELECT INTO ve index oluşturma/rebuild gibi bazı işlemler simple ve bulk-logged modda minimal loglanır; bu da log büyümesini ve işlem süresini azaltır. Full modda ise bu işlemler her zaman tam olarak loglanır.

Simple Recovery Model Hakkında Yaygın Yanılgılar

• “Simple modda log tutulmaz.” Yanlış. Her işlem yine loglanır; bu, crash recovery ve rollback için zorunludur. Fark, log’un ne zaman yeniden kullanılabileceğindedir.
• “Simple model performansı artırır.” Genel olarak hayır. Normal OLTP işlemleri her iki modda da aynı şekilde loglanır. Performans farkı yalnızca minimal loglanabilen bulk işlemlerde görülür.
• “Log diski doldu, simple’a alıp shrink yapalım.” Bu acil durumda sorunu çözer gibi görünse de log zincirini kırar ve point-in-time restore yeteneğini sessizce ortadan kaldırır. Doğru çözüm genellikle log backup almak ve log backup sıklığını düzeltmektir.
• “Differential backup simple modda çalışmaz.” Yanlış. Simple modda full ve differential backup alınabilir; yalnızca log backup alınamaz.

Sık Sorulan Sorular