Transaction Yönetimi: "Ya Hep Ya Hiç"

Merhaba Arkadaşlar!

Takip ediyorsanız görmüşsünüzdür; genelde ORACLE DBMS ve veritabanı üzerine olan kavramlara ait bir takım yazılar paylaşmaya çalışıyorum. Bu kez de veritabanları için kritik önem taşıyan transaction yönetimine değinmek istiyorum.

Transaction nedir ve neden ihtiyaç duyulmuştur sorusuna cevap arayacağımız bu yazı umarım yararlı olabilir. Fakat bu yazıya geçmeden önce transaction hakkında sosyal ortamda gezen bir takım tanımlamalar var. Gayet açıklayıcı ve güzel yorumlanmışlar. Onlara bir bakalım istiyorum:
- Bir işin başarılabilmesi için yapılması gereken minimum işler topluluğu
- Bir SQL sorgusunda bulunan hatayı BACK-UP'lara bulaşmadan kolayca düzeltmenizi sağlayacak, olası veri kaybını önleyecek ve çoğu zaman hayat kurtaracak eylem.
- (Şu çok mantıklı bence:) İşletim sistemindeki thread yapısının veritabanına uyarlanmış hali. (Biliyoruz ki threadler prosesleri oluşturan ve bölünemez durumdaki küçük iş parçacıklarıdır.)
- (Ve nihayeeeet) Veritabanındaki güncelleme gibi işlerin işlemsel bütünlüğünü sağlar. Bir transaction'ın başarılı olması için tüm alt işlemlerin de başarılı gerçekleşmesi gerekir. Eğer bir tane alt işlem sıkıntı yaratırsa tüm transaction iptal edilir. Yani bu işlem yokmuş gibi davranılır ve geri alınır. Eğer tüm alt işlemler başarıyla sonuçlanırsa COMMIT işlemi tetiklenir ve değişiklikler veritabanına uygulanır. Böylelikle işlem bütünlüğü sağlanmış olur.

Evet, tanımlar böyle. Eğer bu tanımları okuyup yazıya devam ederseniz eminim aklınızda bu konuyla ilgili soru kalmaz. Zira yukarıda transaction olayının neredeyse tüm özellikleri açıklanmış ama bazı yerleri üstü kapalı ya da eksik. Bunları izninizle beraber tamamlayıp tanımlayalım:

TRANSACTION YÖNETİMİ

Öncelikle neden transaction yapısına ihtiyaç duyulmuş onu keşfedelim. Her zaman aynı örnek verilir ama gayet anlaşılırdır: Bir banka işlemini düşünelim. Bir hesaptan diğerine para aktarımı gerçekleştirilecek. Yani bildiğimiz klasik havale işlemi. Bize ilk bakışta çekirdek bir işlem gibi görünse de alt yapısında meydana gelen küçük işler mevcut. Gönderici hesaptan para düşülmesi, alıcı hesabın bakiyesinin artırılması, çeşitli kontrol işlemleri... Diyelim ki transaction yapısı kullanmayan bir veritabanımız var. Gönderici hesabından para düşüldüğü anda elektrik kesintisi oluyor ve alıcı hesaba para aktarılamıyor. Bu durumda para nereye gidecek? İşte burada transaction devreye giriyor. Bu tarz veri bütünlüğünün sağlanması transactionla mümkündür. (Veri Bütünlüğü: Bir verinin veritabanına ait tüm tablolarda uyumlu olmasıdır.)

Şimdi tanımı verelim: Bir transaction; birkaç küçük adım içeren ve veritabanının bütünlüğünü bozmayan işlem birimidir. Her transaction kendine ait bir ID değeri vardır ve yok olana kadar bu ID değeri ile yaşar. İşlemler bunun üzerinden devam eder.

Peki transactionlar ne tür alt işlemler içerir?

Örneğin  bir tabloya bir sütun eklemek gibi mantıksal bir işlem, bir takım fiziksel işlemleri içerebilir(index güncellemeleri, trigger işlemleri, rekürsif adımlar).  Yine bir transaction birkaç mantıksal işlemi içeriyor olabilir. 

Bir transactiona ait tüm alt işlemler başarıyla noktalanıncaya kadar bu işlemler fiziksel olarak veritabanına işlenmezler. Hazırda bekletilirler. Bütün ardı ardına yapılacak işlemler başarıyla bittikten sonra COMMIT’lenir ve henüz hiç biri uygulanmamış olan bu işlemler güvenli bir biçimde uygulanır. Eğer bu işlem adımlarında birisinde bir problem olursa transaction'ın tamamı yok sayılarak geri alınır. 

Transaction Özellikleri

Bir DBMS bu transactionları bir takım özellikleri sağlamak durumundadır. Böylelikle istenen veri bütünlüğü sağlanmış olacaktır. Bu özelliklere şifreli olarak ACID denir. Yani;

• Atomicity : Atomiklik
• Consistency : Tutarlılık
• Isolation : İzolasyon
• Durability : Dayanıklılık

Şimdi bu özelliklerin neler olduğunu inceleyelim:

1.) Atomicity

 Konunun daha anlaşılır olması için işletim sistemlerinden bir örnek verelim. Bildiğimiz gibi işletim sistemleri aynı anda birden fazla program çalıştırırlar. Bunları kesme yapılarıyla kontrol ederler. İki program çeşitli kesme algoritmalarıyla paralel olarak çalışabilir. Bu gibi durumda bazı kod parçalarının atomik olması gerekir. Yani işletim sistemi burada bir kesme uygulamamalıdır. Örneğin bir veri girişi esnasında kesme gelirse girdiğiniz verilerin kaybı söz konusu olabilir. Bu nedenle okuma/yazma işlemleri atomiktir. 

Veritabanı işlemlerinin de okuma/yazma işlemleri gibi bir bütün olarak gerçekleşmesi esastır. Bir işlemin herhangi bir ara adımda başarısız olması her zaman mümkündür. Örneğin  bir kullanıcı veritabanına bağlantısını kaybedebilir ya da boş alan kalmayabilir(Elektrik kesintisini hatırlayın). Ya da kullanıcının saklamak istediği yeni veri için yerleştirme mümkün olmayabilir. Eğer bunun gibi bir başarısızlık meydana gelirse, veritabanı yönetim sistemleri ROLLBACK işlemini gerçekleştirir. Yani değişiklikler otomatik olarak geri sarılır. Bu nedenle transactionlar mantıksal açıdan bölünemez veya atomiktir. Transaction ifadesinin bittiğini bildiren bazı durumlar vardır. COMMIT, ROLLBACK transaction'ı bitiren sözlü ifadelerdir. Ya da herhangi bir DDL komutu transaction akışını bozar. Yine veritabanının kapanması da bir transaction olayını sonlandırır.

2.) Consistency

Transactionlar tutarlı olurlar. Bunun aksinin olduğunu düşünelim. Eğer tutarsız olsalardı bir hesaptan para düşmesi durumunda diğer hesaba paranın geçmesi vakit alırdı. Bu işlemlerin aynı anda gerçekleşmesi gerekir(müşteri memnuniyeti. Acil bir durumda paranızı aktarım işleminden yarım saat sonra çektiğinizi düşünün!). Sonuçta transactionlar veritabanının bütünlüğünü riske atmazlar. Bu yüzden DBSM sistemleri tutarlı bir noktadan tutarlı bir noktaya işlemler yaparlar. Bir işleme ait adımlar kendi içerisinde kontrol edilip daha sonra aynı anda veritabanına uygulanırlar.

3.) Isolation

Aynı anda meydana gelen işlemlerde bu işlemler birbirlerinin sonuçlarını etkilememelidir. Yani iki farklı transaction kesinlikle birbiriyle çakışmamalıdır. Her transaction işlemi veritabanının bütünlüğünü kendi içerisinde korumak zorundadır. Zaten belirttiğimiz ID olayı bunu sağlar. 

Bunu şu örnekle açıklayalım: Örneğin bir satış sitesinin veritabanını kontrol ediyoruz. Ve alınacak üründen son bir tane kalmış olsun. İki müşteri bu ürünü incelerken birinci müşteri bu ürünü sepetine eklediğinde diğeri bu ürünü işlem gerçekleşinceye kadar göremez. Yani aynı anda çalışan transactionlar tarafından üretilen sonuçlar tutarlı olmalıdır. Bu ürünün tabloda -1 olarak görülmesini istemiyorsak izolasyonu sağlıyor olmalıyız :) Zaten bu üzerinde çalışılan ve write skew olarak geçen bir problemdir. Çözümünde farklı algoritmalar mevcuttur.

Sonuç olarak bir veritabanı transaction’ı COMMIT’lenmeden bu işleme ait sonuç diğer kullanıcılar tarafından görülmez. Bu hesaplar arasındaki izolasyonu sağlar.

4.) Durability

Başarıyla uygulanmış bir transaction işlemi (COMMIT ile uygulanmış) geri alınamaz. Yani işleme ait tüm adımlar başarıyla uygulanmışsa ve kullanıcı da bundan haberdar edilmişse sonuç diskteki problemlere rağmen kalıcı olmalıdır. Bunun tersini düşünürsek bir ve ya birkaç adımında sıkıntı olan bir transaction için güncelleme yapılmaz. Diskte bir problem olsa bile bu durabilty özelliğini etkilememelidir. 

Ve son olarak tümm bunların sağlanmasıyla Veri Bütünlüğü'nün sağlanacağını anlamış olmalıyız. Yani transaction yönetimi aslında veri bütünlüğünü sağlamaya yöneliktir. Burada yine vurgulayalım: Ya Hep Ya Hiç kuralı mevcut. Yani transaction işlemi başarılıysa hep, başarısızsa hiç :) Bunu alt işlemleri düşünerek yorumlayınız.

Eveeeet, bir yazının daha sonuna geldik. Umarım anlaşılır olmuştur... İyi çalışmalar dilerim!