SQL Rollback Stratejisi: Üç Veritabanı, Üç Farklı Gerçek

Geri alma planı, deployment sunumlarında en kolay yazılan ve gerçekte en az test edilen maddedir. "Sorun olursa geri alırız" cümlesi çoğu zaman bir plan değil, bir temennidir. Üstelik geri almanın nasıl çalıştığı kullandığınız veritabanına göre ciddi biçimde değişir.

Yaygın Yanılgı: Yedeğim Var

Yedek bir geri alma planı değil, felaket kurtarma planıdır. Aradaki fark süredir ve kapsamdır. Büyük bir veritabanını geri yüklemek saatler sürer ve o süre boyunca sistem kapalıdır. Dahası, yedekten dönüş hatalı işlemden sonra oluşan doğru işlemleri de siler. Bir tabloda yanlış güncelleme yaptınız diye o saat içinde alınan gerçek siparişleri kaybetmek, çözümün kendisini yeni bir olaya dönüştürür.

Bu yüzden gerçek geri alma planı, karşıt işlemleri içeren bir script olmalıdır: eklenen kaydı silen, silinen kaydı geri yazan, değiştirilen yapıyı eski haline getiren bir script.

Üç Motor, Üç Farklı Davranış

Oracle tarafındaki fark, geri alma stratejisinin tamamını değiştirir. Bir script içinde beş DDL cümlesi varsa ve üçüncüsü hata verirse, ilk ikisi çoktan kalıcı olmuştur. "Hepsi ya da hiçbiri" garantisi yoktur. Bu durumda geri alma script'i, hangi adımların gerçekleştiğini bilmeden çalışabilmelidir.

Idempotent Geri Alma Neden Şart?

Idempotent, aynı script'i iki kez çalıştırmanın bir kez çalıştırmakla aynı sonucu vermesi demektir. Geri alma script'inde bu özellik lüks değil zorunluluktur, çünkü geri almayı çalıştırdığınızda sistemin hangi noktada olduğundan emin değilsinizdir. Belki değişikliğin yarısı uygulandı, belki hiçbiri, belki biri daha önce elle geri aldı.

Pratikte bu, her adımın önce varlık kontrolü yapmasını gerektirir: silmeden önce var mı diye bakmak, eklemeden önce zaten var mı diye kontrol etmek. "Nesne yok" hatasıyla duran bir geri alma script'i, en kötü anda işe yaramaz hale gelir.

DML Geri Alması: En Zor Kısım

Yapı değişikliğini geri almak görece kolaydır: eklenen kolonu silersiniz. Veri değişikliğini geri almak ise eski değeri bilmeyi gerektirir. Bir güncelleme yapmadan önce etkilenecek satırların eski hallerini bir yedek tabloya almak, en güvenilir yöntemdir. Bu adım script'i biraz uzatır ama geri dönüşü mümkün kılan tek şeydir.

Gerçekçi Bir Geri Alma Planı

Gerçekçi bir plan şu beş özelliği taşır:

• Değişiklikle birlikte üretilir. Sonradan yazılan geri alma script'i çoğu zaman hiç yazılmaz.
• Talebin parçasıdır. Ayrı bir dosyada duran script, ihtiyaç anında bulunamaz.
• Idempotenttir. Yarım kalmış bir durumda da çalışır.
• Denenmiştir. Hiç çalıştırılmamış bir geri alma script'i, plan değil varsayımdır.
• Zorunlu tutulabilir. Kritik ortamlarda geri alma script'i olmayan bir değişiklik çalıştırılmamalıdır.

Bu beş maddenin hepsini elle yürütmek mümkündür ama pratikte sürdürülemez. Bu yüzden geri alma üretimi otomatikleştirilmeli, üretilen script insan tarafından gözden geçirilmeli ve varlığı sistem tarafından denetlenmelidir.

Sık Sorulan Sorular

Yedeğimiz varsa geri alma planına neden ihtiyaç duyalım?

Yedek bir kurtarma aracıdır, geri alma planı bir değişiklik aracıdır. Yedekten dönmek çoğu zaman tüm veritabanını o ana taşır, yani araya giren diğer işlemleri de siler. Tek bir değişikliği geri almak istediğinizde yedek genellikle çok geniş ve çok yavaş bir çözümdür.

Oracle'da geri alma neden farklı çalışıyor?

Oracle'da DDL ifadeleri örtülü bir commit üretir: tabloyu değiştiren bir ifade çalıştığı anda kalıcı olur ve işlem geri alınamaz. SQL Server ve PostgreSQL'de DDL çoğu durumda işleme dahil edilebilir. Bu fark, Oracle'da geri alma planının işlem sonrası tek güvence olması demektir.

Geri alma betiği neden idempotent olmalı?

Çünkü geri alma çoğu zaman yarım kalmış bir durumun üzerine çalışır: değişikliğin bir kısmı uygulanmış, bir kısmı uygulanmamıştır. Var olan nesneyi tekrar yaratmaya çalışan bir betik ilk hatada durur ve durumu daha da karışık bırakır. İdempotent betik hangi noktadan başlarsa başlasın aynı sonuca varır.