SQL Server Otomatik Kurtarma (Recovery) İşlemi

Her ne kadar sunucular sürekli çalışmak için tasarlanmış olsalar da; elektrik kesilmesi, güç kaynağı bozulması, işlemcilerin yanması,RAM hataları gibi sorunlar sunucunun kapanmasına neden olabilir.

SQL

SQL Server Otomatik Kurtarma (Recovery) İşlemi
Her ne kadar sunucular sürekli çalışmak için tasarlanmış olsalar da; elektrik kesilmesi, güç  kaynağı bozulması, işlemcilerin yanması,RAM hataları gibi sorunlar sunucunun kapanmasına neden olabilir. İstem dışı bir kapanma sonucunda, SQL Server Buffer Cache ve Log Buffer gibi RAM bölgelerinde yer alan veriler kaybedilir. Bu durumda, SQL Server'in henüz Transaction Log'lara kaydedemediği verilerle ilgili otomatik kurtarma işlemi (SQL Server Automatic Recovery) SQL Server Servisinin çalışması ile devreye girer. Bu işlem sayesinde, veritabanı erişime açılma öncesinde, SQL Server tarafından harici bir müdahele gerekmeksizin, son kapanan transaction noktasına kadarki değişiklikler yapılarak, veritabanı kararlı hale getirilir.

Otomatik Kurtarma, öncelikle Log dosyasına göre COMMIT olan ama diske yansımamış transaction'lar varsa ileri sarma (ROLLFORWARD) işlemine tabi tutar ve logları 'uygulandı' olarak işaretler. Bütün loglar bittiğinde, açık kalan transactionlar varsa (bir transaction COMMIT ile sonlanmamışsa açık kalmış demektir) geri sarım (ROLLBACK işlemi) işlemine tabi tutulur. Böylelikle son biten sağlıklı transaction noktasına veritabanı geri döndürülmüş olur ve kararlı bir noktaya getirilmiş olur.

Veritabanı Loglama Seçeneklerini Anlamak

Her bir veritabanı için transaction log dosyasına yansıtılacak logların seviyeleri ayarlanabilir. Simple, Bulk Logged ve Full Recovery olmak üzere 3 farklı loglama seviyesi mevcuttur. Loglama seviyelerini veritabanının kritikliği belirler. SQL Server'da oluşturulan yeni bir veritabanı için varsayılan seviye Full Recovery seviyesidir. Bu seviyede her değişim loglanır. Simple Recovery modda ise sadece verilerin tutarlılığını garanti edecek kadar log tutulur.

• Simple Recovery Model: Sadece okunan veritabanları, test veritabanları gibi değişimi ve veri kaybı önemli olmayan veya belli bir zamana dönme zorunluluğu gerektirmeyen veritabanları için tercih edilebilir. Bu modda çalışan bir veritabanının log dosyası belli bir boyutun üstüne çıkmaz. Log bilgisini yedekleme gereksinimi yoktur. Loglar sadece 'uygulandı' olarak işaretlenene kadar tutulur. Aktifliği biten loglar silinir. Bakımı kolaydır. Ancak her hangi bir zamana dönmek mümkün değildir. Sadece tam veritabanı yedeği (full database backup) alınan zamanlara dönülebilir. Kritik uygulamalar bu modda tutulmamalıdır.
• Full Recovery Model: Bütün değişimler loga yansıtılır. Yedek alınana kadar loglar bekler. İstenilen noktaya dönülebilir. Ancak uzun süre loglar yedeklenmezse, log dosyaları aşırı büyüyebilir. Bu modda yedek alınan transaction log yedekleri arasında kayıp yapılmaması çok önemlidir. Zincirin kırılması (aradan bir yedeğin kaybolması) halinde her hangi bir zamana dönmek imkansızlaşacaktır. Bu modda, tam veritabanı yedekleme (full database backup) işleminin yanı sıra, özellikle çok işlem olan veritabanları için, SQL Server'a tanımlanacak bir zamanlanmış plan ile logların belli aralıklarla yedeklenmesi yararlı olacaktır.
• Bulk-Logged Recovery Model: Bu model, Simple ile Full recovery modelin arasında kalan bir modeldir. SELECT INTO, bcp ile yapılan yüklemeler, CREATE ALTER INDEX REBUILD-DROP INDEX gibi toplu işlemler loga düşmez. Şayet veritabanı üstünde Mirroring gibi bir log dosyası üstünden çalışan servis yoksa; Full Recovery ile bulk log arasında yukarıda sayılan durumlarda log dosyasının boyutunu fazla uzatmamak için geçiş yapılabilir. Bu türden bir servis varsa veritabanı Full Recovery modelde tutulmalıdır.

Kaynak: Yazılımcılar İçin SQL Server 2014 ve Veritabanı Programlama -Yaşar GÖZÜDELİ