Konuyu Açan #1
SQL Transaction Log Analizi ve Kurtarma

Günlükler, bir veritabanının kalp atışını gösterir: her değişiklik, işlem sınırları ve geri alma imkânları burada saklıdır. Ancak büyük veritabanlarında Transaction Log’u etkili kullanmak, hasar sonrası kurtarma süreçlerini hızlandırır ve beklenmedik veri kaybını minimize eder. Bu yazıda, log dosyalarının yapısını çözümlemekten başlayıp, pratik kurtarma senaryolarına kadar ilerleyeceğim.


Giriş ve temel kavramlar
Transaction Log, veritabanı motorunun tüm değişiklikleri kaydettiği sürekli büyüyen bir günlük dosyasıdır. Her işlem, veri değişikliklerini ve bu değişikliğin geri alınabilirliğini güvenli bir şekilde kayıt altına alır. Log, iki ana amaç için kullanılır: ACID güvenliğini sağlamak ve hasar durumunda geri dönüş işlemlerini yürütmek. Özellikle büyük işlemlerde log yoğunluğu artar; oturum başına kullanılan log blokları, redo/undo işlemlerinin temelini oluşturur.

Log segmentasyonu ve ana kavramlar
  • LSN (Log Sequence Number): Her kayıtlı değişikliğin benzersiz sıralama numarası.
  • Varlık-uyumu (Recovery Models): Tam, Basit veya Büyük Kayıt modu gibi seçenekler, logların nasıl ve ne kadar süreyle tutulacağını belirler.
  • TRN (Transaction Roll Forward/Backward): Kurtarma sırasında redo ve undo işlemleri için kullanılır.
  • Active ve Inactive Loglar: Aktif olanlar yazma devam edenler; arşivlenenler, kurtarma için kullanılabilir durumda olanlardır.


Hasar sonrası kurtarma stratejileri
1) Son tam yedek ve sonraki log aralığıyla geri yükleme: Önce tam yedek geri yüklenir, ardından log yedekleri sırasıyla uygulanır; gerektiğinde punto düzeyinde sayfa geri yüklemeleriyle tutarlı bir durum elde edilir.
2) Aşırı büyümüş loglar için sıkıştırma ve arşiv: Log dosyasının zaman içinde çok büyümesini engellemek amacıyla arşivleme stratejileri uygulanır; bu işlem performansı doğrudan etkiler.
3) Bozulma tespitinde log-only kurtarma: Log dosyaları bozulduğunda, yedekler ve loglar arasındaki bağların yeniden kurulması için özel adımlar gerekir; bazı motorlar bu duruma karşı tercihler sunar.
4) Nokta-in-time kurtarma: Spesifik bir zaman damgasına geri dönerek işlemleri geri almak veya yeniden uygulamak mümkündür; bu, hangi işlemlerin etkisini anlamsız kılar, hangi işlemlerin korunması gerektiğini netleştirir.

Pratik ipuçları ve günlük rutinler
  • Log dosyalarını periyodik olarak temizlemek için bakım planı oluşturun; büyümeyi sınırlandıran otomatik büyüme stratejileri riskleri azaltır.
  • Sık sık test kurtarmaları yapın; hedef, gerçekya kurtarmanın sorunsuz gerçekleşmesini sağlamaktır.
  • Hasar tespitinde değişiklik bağlamını kaybetmeden, hangi işlem grubunun hangi tabloya dokunduğunu izlemek için uygun araçlar kullanın.
  • Büyük işlemler öncesi commit noktalarını ve log kullanımını analiz edin; uzun süren işlemlerde log bozulmasına karşı özel strateji belirleyin.


Sonuç
Transaction Log Analizi ve Kurtarma, veritabanı operasyonlarının güvenilirliğini sağlayan kritik bir alandır. Doğru kavramlar, düzenli bakım ve gerçekçi kurtarma testleriyle, veri kaybı riskini anlamlı ölçüde azaltmak mümkün olur. Log yapısının nasıl çalıştığını anladıktan sonra, hangi durumda hangi yöntemi seçeceğinize dair net bir içgörü elde edersiniz. Bu konudaki deneyimlerinizi ve hangi araçlarla pratik kontroller yaptığınızı paylaşabilirsiniz.

Yanıt vermek için giriş yapmış olmalısınız.

Bu konuyu görüntüleyen kullanıcılar (Toplam: 5, Üyeler: 5, Misafirler: 0)
Toplam: 5 (üyeler: 5, misafirler: 0)
0 alıntı seçildi