SQL'de Transaction Kullanımı: Onaylama, Geri Alma, Kayıt Noktası

Transaction nedir ve neden gerekir?

Transaction (işlem), veritabanında birlikte başarılı olması ya da birlikte hiç gerçekleşmemesi gereken komutlar grubudur. Klasik örnek para transferidir: bir hesaptan düşme ve diğerine ekleme komutları ayrı ayrı çalıştırılırsa, araya giren bir hata para kaybına yol açar. Aynı komutlar bir transaction içine alınırsa ya ikisi de kalıcı olur ya da ikisi de geri alınır.

Bu davranış ACID olarak özetlenen özelliklere dayanır: atomiklik (ya hep ya hiç), tutarlılık (kurallara uygun durum), izolasyon (eşzamanlı işlemlerin birbirini bozmaması) ve dayanıklılık (onaylanan değişikliğin kalıcılığı). Pratikte SQL yazan biri için ilk ikisi günlük işin parçasıdır: birden çok tabloya yazan her işlem, tek bir transaction olarak düşünülmelidir.

Transaction yazmadığınızda da veritabanı genellikle her komutu kendi küçük işleminde çalıştırır (otomatik onay). Sorun, birden çok komutun mantıksal olarak tek iş olduğu durumda ortaya çıkar: sipariş başlığını yazıp kalemleri yazmadan hata alan bir uygulama, kalemsiz sipariş bırakır.

COMMIT ve ROLLBACK temel akışı

Temel akış şu adımlardan oluşur: işlemi başlat, değişiklikleri yap, sonra onayla ya da geri al. PostgreSQL'de başlangıç BEGIN ile yapılır:

BEGIN; UPDATE hesap SET bakiye = bakiye - :tutar WHERE hesap_no = :kaynak; UPDATE hesap SET bakiye = bakiye + :tutar WHERE hesap_no = :hedef; COMMIT;

COMMIT, bu bloktaki tüm değişiklikleri kalıcı yapar ve diğer oturumlara görünür kılar. Bir sorun fark edilirse COMMIT yerine ROLLBACK çalıştırılır; blok içindeki hiçbir değişiklik uygulanmamış sayılır.

SQL Server'da söz dizimi BEGIN TRANSACTION, COMMIT TRANSACTION ve ROLLBACK TRANSACTION biçimindedir. MySQL'de (InnoDB motoru) işlem START TRANSACTION ile başlar; otomatik onay açıkken tek komutlar anında onaylanır, START TRANSACTION ile açılan blokta ise COMMIT gelene kadar bekler. Söz dizimi farkları küçüktür; mantık aynıdır.

Önemli bir ayrıntı: açık bırakılmış transaction. COMMIT ya da ROLLBACK yazılmadan bırakılan bir oturum kilit tutmaya devam eder ve başkalarını bekletir. Sorgu aracında elle çalışırken işlem bittiğinde mutlaka birini çalıştırın.

Hatayı yakalayıp geri almak

Gerçek uygulamada ROLLBACK elle değil, hata durumunda otomatik çalışmalıdır. SQL Server'da bunun yaygın biçimi TRY...CATCH bloğudur:

SET XACT_ABORT ON; BEGIN TRY BEGIN TRANSACTION; -- sipariş başlığı ve kalemleri yazılır COMMIT TRANSACTION; END TRY BEGIN CATCH IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION; THROW; END CATCH;

XACT_ABORT açık olduğunda çalışma zamanı hatalarında işlem otomatik iptal edilir; böylece yarım kalan bir transaction'ın açık kalma riski azalır. CATCH bloğunda işlem sayacı kontrol edilir, açık işlem varsa geri alınır ve hata yeniden fırlatılır. Hatanın sessizce yutulması, "işlem tamamlandı" izlenimi verip veriyi yarım bırakabilir.

PostgreSQL ve MySQL'de hata yönetimi genellikle uygulama katmanında yapılır: uygulama, işlem içinde bir hata alırsa ROLLBACK gönderir. Saklı yordam içinde istisna bloğu da kullanılabilir. PostgreSQL'de bir hata aldığınızda işlem bloğu iptal durumuna girer ve bundan sonra geri alma dışında komut kabul etmez; bu davranış, hatadan sonra devam etmeye çalışan uygulamalarda şaşırtıcı olabilir.

SAVEPOINT ile kısmi geri alma

Bazen işlemin tamamını değil, yalnızca son adımları geri almak istenir. Bunun aracı SAVEPOINT'tir:

BEGIN; UPDATE hesap SET bakiye = bakiye - :tutar WHERE hesap_no = :kaynak; SAVEPOINT alacak_oncesi; UPDATE hesap SET bakiye = bakiye + :tutar WHERE hesap_no = :yanlis_hedef; ROLLBACK TO SAVEPOINT alacak_oncesi; UPDATE hesap SET bakiye = bakiye + :tutar WHERE hesap_no = :dogru_hedef; COMMIT;

ROLLBACK TO yalnızca kayıt noktasından sonraki değişiklikleri siler; öncesi işlemde kalır. PostgreSQL belgelerindeki örnek de aynı yapıyı kullanır. SQL Server'da kayıt noktası SAVE TRANSACTION adıyla kullanılır. Pratik kullanım alanı, uzun bir toplu işlemde tek bir kaydın hatası yüzünden tüm işi baştan çalıştırmak istemediğiniz durumlardır.

İzolasyon seviyeleri neyi değiştirir?

Aynı anda çalışan transaction'lar birbirinin yaptığı değişiklikleri hangi koşullarla görür? Bu sorunun cevabı izolasyon seviyesidir. Yaygın seviyeler okuma onaylanmamış, okuma onaylanmış, tekrarlanabilir okuma ve serileştirilebilir olarak anılır; ürüne göre varsayılan ve davranış farklıdır.

Düşük izolasyonda şu anomaliler görülebilir:

• Kirli okuma: henüz onaylanmamış bir değişikliğin başka oturumca okunması
• Tekrarlanamayan okuma: aynı satırı tekrar okuyan işlemin farklı değer görmesi
• Hayalet satır: aynı sorguyu tekrarlayan işlemin yeni satırlar görmesi

Yüksek izolasyon bu anomalileri engeller ama bekleme, kilitlenme ve geri alma ihtimalini artırır. Bu yüzden her transaction'ı en yüksek seviyede çalıştırmak çözüm değildir; işin gerektirdiği tutarlılık ile eşzamanlılık maliyeti dengelenir. Bakiye gibi kritik hesaplamalarda yüksek seviye, rapor sorgularında düşük seviye makul olabilir. Ürününüzün varsayılan seviyesini ve belirli seviyeyi nasıl seçtiğini kendi veritabanı belgesinden kontrol edin.

Kilitlenme ve transaction süresi

Birbirini bekleyen işlemler kilitlenme (deadlock) oluşturur: biri diğerinin tuttuğu satırı, diğeri de ilkinin tuttuğunu bekler. Veritabanı bunu fark ettiğinde işlemlerden birini iptal eder ve uygulamaya hata döner. Çözüm, hatayı yakalayıp işlemi yeniden denemektir.

Kilitlenme olasılığını azaltan alışkanlıklar şunlardır:

• Tabloları ve satırları her işlemde aynı sırayla güncellemek
• Transaction'ı kısa tutmak; kullanıcı girişi ya da dış çağrı beklerken işlem açık tutulmaz
• Gereksiz yere geniş bir veri aralığını kilitlememek; güncellemelerde WHERE koşulunu dar tutmak
• Uzun toplu işlemleri parçalara bölmek

Uzun süren transaction yalnızca kilit sorunu yaratmaz; geri alma gerektiğinde de uzun sürer. Çok büyük bir güncellemeyi tek işlemde yapmak yerine parçalar halinde yapmak, hem geri dönülebilirlik hem de sistem yükü açısından daha güvenlidir.

Sık yapılan hatalar ve güvenli kullanım listesi

Yeni başlayanların sık yaptığı hatalar:

• COMMIT ya da ROLLBACK'i unutup oturumu açık bırakmak
• Ekleme ve güncelleme yapan çok adımlı iş akışlarını transaction'a almamak
• CATCH bloğunda hatayı yutmak
• DDL komutlarının her veritabanında aynı davranmadığını bilmemek: PostgreSQL'de tablo oluşturma gibi şema değişiklikleri işlemin parçası olarak geri alınabilirken, MySQL'de bu komutlar örtük onay tetikleyip açık işlemi bitirebilir
• Üretimde, WHERE koşulunu doğrulamadan UPDATE çalıştırmak

Güvenli çalışma listesi olarak şu sıra önerilir: önce SELECT ile etkilenecek satırları görün, BEGIN ile işlemi açın, değişikliği çalıştırın, etkilenen satır sayısına ve sonuca bakın, doğruysa COMMIT, şüpheliyse ROLLBACK yapın. Veri düzeltme işlerinin tamamı için SQL UPDATE ve DELETE güvenli kullanımı sayfası bu alışkanlığı ayrıntılı işler.

Mindset programlarında bu beceri nerede çalışılır?

Transaction yönetimi, hem veri analistleri hem de uygulama geliştiricileri için önemlidir: yalnızca sorgu yazanlar bile veri düzeltme betiklerini güvenli yazmak zorundadır. Mindset'in Veritabanı İşlem Yönetimi ve İzolasyon Seviyeleri programı işlem temelleri ve ACID, izolasyon seviyeleri ve okuma anomalileri, kilitleme ve eşzamanlılık kontrolü, uygulama katmanı desenleri ve tasarım başlıklarını ayrı modüllerde ele alır. Bu program, uygulama ya da veri ekibinde eşzamanlılık sorunlarıyla karşılaşan geliştirici ve veri mühendisleri için uygundur.

SQL ile Veri Sorgulama (İleri) programı ise alt sorgu, görünüm, saklı yordam ve tetikleyici gibi konularda transaction kullanımının günlük işte karşılaşıldığı bağlamı sunar. Kurumsal bir ekipte veri ekibi ile uygulama ekibini aynı işlem mantığı üzerinde buluşturmak mümkündür. Kapsam ayrıntısı program sayfalarında yer alır.