Transaction Management - Database Management System

01 — Temel Kavram

Transaction Nedir?

Bir transaction, tek bir işlem gibi davranan bir grup operasyondur. Tüm operasyonlar başarıyla tamamlanır ya da hiçbiri tamamlanmaz. Bu, veritabanının tutarlılığını korumanın temelidir.

Birden fazla istemci aynı arabellek (buffer) üzerinde eş zamanlı işlem yaptığında ciddi sorunlar ortaya çıkabilir: bir istemci tutarsız değerler görebilir ya da iki istemci birbirinin yazdığı değerlerin üzerine yazabilir. Veritabanı sistemi bu kaos ortamını iki temel bileşenle düzenler:

⚡ Recovery Manager

Log dosyasını okur ve yazar
Atomicity ve Durability'yi güvence altına alır
Sistem çökmelerinden sonra veritabanını kurtarır

🔒 Concurrency Manager

Transaction'ların çalışmasını düzenler
Isolation'ı sağlar
Eş zamanlı erişimi kontrol eder

Klasik Örnek: Para Transferi ($50)

A hesabından B hesabına 50 dolar transfer eden bir transaction şu adımlardan oluşur:

Adım	Operasyon	Türü	Açıklama
1	read(A)	Okuma	A'nın değerini diskten belleğe al
2	A := A – 50	Hesaplama	Bellekteki A değerini güncelle
3	write(A)	Yazma	Güncellenmiş A'yı diske yaz
4	read(B)	Okuma	B'nin değerini diskten belleğe al
5	B := B + 50	Hesaplama	Bellekteki B değerini güncelle
6	write(B)	Yazma	Güncellenmiş B'yi diske yaz

⚠️

Kritik Sorun: Sistem 3. adımdan sonra, 6. adımdan önce çökerse A'dan 50 TL çıkmış ama B'ye eklenmemiş olur. Para "kaybolur"! İşte ACID özellikleri tam olarak bu tür durumları önlemek için tasarlanmıştır.

02 — Temel Özellikler

ACID Özellikleri

Veritabanı sistemlerinin veri bütünlüğünü korumak için sağlaması gereken dört temel özelliktir. Her özellik, farklı bir sorun türüne karşı koruma sağlar.

A

Atomicity

"Ya hepsi ya hiçbiri" ilkesi. Tüm operasyonlar başarılı olur (commit) veya hepsi geri alınır (rollback). Kısmi sonuç kabul edilmez.

C

Consistency

Her transaction veritabanını tutarlı bir durumdan başka bir tutarlı duruma taşır. A+B toplamı transaction öncesi ve sonrası aynı kalır.

I

Isolation

Transaction'lar birbirinden izole çalışır. Bir transaction, diğerinin kısmen tamamlanmış sonuçlarını görmemeli. Sanki sistemde tek transaction var gibi davranır.

D

Durability

Commit edilen bir transaction'ın değişiklikleri kalıcıdır. Yazılım veya donanım arızası olsa bile sonuçlar korunur.

Isolation Problemi: Görsel Örnek

T1 transaction'ı çalışırken T2 araya girerse tutarsız veri okur:

        Isolation Sorunu — T1 vs T2 Eş Zamanlı Çalışma
      

                T1                              T2
        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
        1. read(A)                    
        2. A := A – 50               
        3. write(A)   ← A güncellendi
                                      → read(A), read(B), print(A+B)
                                      ↑ T2 yanlış sonuç görür! A+B eksik
        4. read(B)                    
        5. B := B + 50               
        6. write(B)   ← B güncellendi
      

💡

Çözüm: Isolation, transaction'ları seri (biri bittikten sonra diğeri) çalıştırarak garantilenebilir. Ancak bu performansı düşürür. Modern sistemler eş zamanlılığı izole kalarak sağlamak için kilitleme (locking) mekanizmaları kullanır.

03 — Kurtarma Yöneticisi

Recovery Manager

Recovery Manager, Atomicity ve Durability'den sorumlu olan sunucu bileşenidir. Log dosyasını okur ve işler. Üç temel görevi vardır:

Log Kayıtları Yazma Her transaction operasyonu için log dosyasına kayıt ekler. Bu kayıtlar, geri alma (rollback) için gereklidir.

Transaction Rollback Bir transaction başarısız olduğunda, log dosyası geriye doğru okunarak yapılan tüm değişiklikler geri alınır.

Sistem Çökmesinden Sonra Kurtarma Sistem her yeniden başladığında çalışır. Tamamlanmamış transaction'ları geri alır, commit edilmiş olanları diske yazar.

Sistem Kurtarma Mantığı

⟲ Geri Alınacaklar (UNDO)

Tamamlanmamış transaction'ların değişiklikleri
Log'da COMMIT veya ROLLBACK kaydı olmayan transaction'lar
Kısmen yazılmış, tutarsız veriler

⟳ Yeniden Uygulanacaklar (REDO)

Commit edilmiş transaction'ların değişiklikleri
Log'da COMMIT kaydı olan transaction'lar
Belleğe yazılmış ama diske flushed edilmemiş olabilenler

04 — Log Kayıt Yapısı

Log Kayıt Türleri

Recovery Manager beş tür log kaydı yazar. Her kayıt, transaction'ın hangi aşamada olduğunu belgeler.

START

Transaction başladığında yazılır

SETINT

Tam sayı değeri değiştirildiğinde

SETSTRING

Metin değeri değiştirildiğinde

COMMIT

Transaction başarıyla tamamlandı

ROLLBACK

Transaction geri alındı

Update Kayıtlarının Yapısı

SETINT ve SETSTRING kayıtları, temel iki alana (tür + tx ID) ek olarak 5 değer daha içerir:

        Örnek Log Dosyası — Tüm Alanlar Açıklamalı
      

        <START,    1>                              ← Tx #1 başladı
        <COMMIT,   1>                              ← Tx #1 başarıyla tamamlandı
        
        <START,    2>                              ← Tx #2 başladı
        <SETINT,   2, testfile, 1, 80, 1, 2>     ← Güncelleme
                   │  txID   dosya   blok  offset eski  yeni
        <SETSTRING,2, testfile, 1, 40, one, one!>
        <COMMIT,   2>                              ← Tx #2 commit
        
        <START,    3>                              ← Tx #3 başladı
        <SETINT,   3, testfile, 1, 80, 2, 9999>
        <ROLLBACK, 3>                              ← Tx #3 geri alındı!
        
        <START,    4>
        <COMMIT,   4>
      

Alan	Örnek Değer	Açıklama
Kayıt Türü	SETINT	Log kaydının tipi
Transaction ID	2	Hangi transaction'ın kaydı
Dosya Adı	testfile	Değiştirilen dosyanın adı
Blok Numarası	1	Dosya içindeki blok numarası
Offset	80	Blok içindeki byte konumu
Eski Değer	1	Değişmeden önceki değer (undo için)
Yeni Değer	2	Değişmeden sonraki değer (redo için)

Rollback Algoritması

Recovery Manager, bir transaction'ı geri almak için log dosyasını geriye doğru okur:

Figür 14-5 — Transaction T için Rollback Algoritması

UNDO Geri Alma Adımları

1. Mevcut kaydı en son log kaydına ayarla
2. Mevcut kayıt T'nin başlangıç kaydı olana kadar devam et:
a) Eğer mevcut kayıt T'nin update kaydıysa → eski değeri belirtilen konuma geri yaz
b) Önceki log kaydına geç
3. Log dosyasına bir ROLLBACK kaydı ekle

05 — Kurtarma Algoritmaları

Recovery Algoritmaları

Üç farklı recovery algoritması vardır. Her biri farklı bir strateji kullanır ve farklı trade-off'ları vardır.

Figür 14-6 — Undo-Redo Kurtarma Algoritması (En Yaygın)

UNDO Aşaması Log sonda başlanır, geriye okunur

Her log kaydı için (sondan başa doğru okunarak):
a) Eğer COMMIT kaydıysa → o transaction'ı "tamamlanmış listesi"ne ekle
b) Eğer ROLLBACK kaydıysa → o transaction'ı "geri alınmış listesi"ne ekle
c) Eğer UPDATE kaydıysa ve transaction tamamlanmış/geri alınmış değilse → eski değeri geri yaz (UNDO)

REDO Aşaması Log baştan okunur, ileriye gidilir

Her log kaydı için (baştan sona doğru okunarak):
Eğer UPDATE kaydıysa ve transaction tamamlanmış listedeyse → yeni değeri tekrar yaz (REDO)

🔄 Undo-Only

Sadece geri alma yapar
Commit sonrası değişiklikler diske yazılır
Crash sonrası redo gerekmez
Buffer flush maliyeti yüksek

⏩ Redo-Only

Sadece ileriye alma yapar
Commit öncesi değişiklikler diske yazılmaz
Crash sonrası undo gerekmez
Log boyutu büyük olabilir

06 — Önceden Yazma İlkesi

Write-Ahead Logging (WAL)

Undo-Redo algoritması, tamamlanmamış bir transaction'ın tüm update kayıtlarının log dosyasında bulunduğunu varsayar. Ancak sistem çökmesi her an gerçekleşebilir. Bu durumda ne olur?

Dört Olası Senaryo

Tamamlanmamış bir transaction bir sayfayı değiştirdiğinde ve eşleşen log kaydı oluşturulduğunda sistem çökerse:

✅ A) Her İkisi de Diske Yazıldı

Recovery algoritması log kaydını bulur ve değişikliği geri alır. Sorun yok.

❌ B) Sadece Sayfa Diske Yazıldı

Recovery algoritması log kaydını bulamaz, değişikliği geri alamaz. Ciddi problem! Veritabanı tutarsız kalır.

⚠️ C) Sadece Log Diske Yazıldı

Recovery algoritması log kaydını bulur, var olmayan değişikliği "geri alır". Zaman kaybı ama hata değil.

✅ D) Hiçbiri Diske Yazılmadı

Recovery algoritması log kaydı bulamaz ama zaten değiştirilecek şey de yok. Sorun yok.

🚨

Senaryo B kritik bir sorundur. Bunu önlemek için Write-Ahead Logging (WAL) kuralı uygulanır.

✅

WAL Kuralı: Değiştirilen bir buffer (arabellek) diske yazılmadan önce, o değişikliğe ait tüm update log kayıtları mutlaka önce diske yazılmış olmalıdır. Bu kural, veritabanındaki tüm değişikliklerin her zaman log'da bulunmasını ve dolayısıyla her zaman geri alınabilmesini garanti eder.

        WAL İlkesi — İşlem Sırası
      

        // Doğru sıra (WAL):
        1. UPDATE log kaydını LOG DOSYASINA yaz  ← Önce log!
        2. Log kaydını diske FLUSH et
        3. Buffer'daki değişikliği diske yaz      ← Sonra data!
        
        // Yanlış sıra (WAL ihlali):
        1. Buffer'daki değişikliği diske yaz      ← YASAK!
        2. UPDATE log kaydını log dosyasına yaz   ← Çok geç
      

07 — Checkpoint Mekanizmaları

Checkpointing

Zamanla log dosyası çok büyük hale gelir. Recovery algoritması, tüm log geçmişini taramak zorunda kalır. Checkpoint kayıtları, algoritmanın daha eski log kayıtlarına bakmasına gerek kalmadığını gösteren işaretçilerdir.

Quiescent Checkpointing

Sistem tüm transaction'ları durdurup bekler, tamamlayıp, sonra checkpoint yazar:

Figür 14-9 — Quiescent Checkpoint Algoritması

1. Yeni transaction kabul etmeyi durdur
2. Mevcut transaction'ların bitmesini bekle
3. Tüm değiştirilmiş buffer'ları diske yaz (flush)
4. Log'a <CHECKPOINT> kaydı ekle ve diske yaz
5. Yeni transaction kabul etmeye yeniden başla

        Quiescent Checkpoint Kullanan Örnek Log
      

        <START, 0>
        <SETINT, 0, junk, 33, 8, 542, 543>
        <START, 1>
        <START, 2>
        <COMMIT, 1>
        <SETSTRING, 2, junk, 44, 20, hello, ciao>
            // Quiescent checkpoint prosedürü başlıyor
        <SETSTRING, 0, junk, 33, 12, joe, joseph>
        <COMMIT, 0>
            // Tx 3 başlamak istiyor ama beklemek zorunda
        <SETINT, 2, junk, 66, 8, 0, 116>
        <COMMIT, 2>
        <CHECKPOINT>  ← Buradan öncesi artık taranmak zorunda değil!
        <START, 3>
        <SETINT, 3, junk, 33, 8, 543, 120>
      

Nonquiescent Checkpointing

Sistemi durdurmadan checkpoint alınır. Çalışan transaction'lar kayıt altına alınır:

Figür 14-11 — Nonquiescent Checkpoint Algoritması

1. Yeni transaction kabul etmeyi geçici olarak durdur
2. Hâlâ çalışan transaction'ları T₁, ..., Tₖ olarak belirle
3. Tüm değiştirilmiş buffer'ları diske yaz (flush)
4. <NQCKPT, T₁, ..., Tₖ> kaydını log'a yaz
5. Yeni transaction kabul etmeye yeniden başla

        Nonquiescent Checkpoint Kullanan Örnek Log
      

        <START, 0>
        <SETINT, 0, junk, 33, 8, 542, 543>
        <START, 1>
        <START, 2>
        <COMMIT, 1>
        <SETSTRING, 2, junk, 44, 20, hello, ciao>
        <NQCKPT, 0, 2>  ← Tx 0 ve Tx 2 hâlâ çalışıyor
        <SETSTRING, 0, junk, 33, 12, joe, joseph>
        <COMMIT, 0>
        <START, 3>  ← Tx 3 checkpoint beklemeden başlayabilir
        <SETINT, 2, junk, 66, 8, 0, 116>
        <SETINT, 3, junk, 33, 8, 543, 120>
      

⏸ Quiescent

Sistem durur, tüm tx biter
<CHECKPOINT> sonrası hiçbir şey taranmaz
Basit ama sistem kesintisi var
Düşük trafik dönemlerinde ideal

▶️ Nonquiescent

Sistem çalışmaya devam eder
En erken tx'nin START'ına kadar taranır
Daha karmaşık ama kesinti yok
Yüksek trafik ortamları için ideal

Checkpoint Sonrası Kurtarma Örneği

Aşağıdaki senaryoda tf anında sistem çökmüş, en yakın checkpoint tc anında alınmıştır:

Zaman Çizelgesi

✅ Dahil Değil

⟳ REDO

⟲ UNDO

⟳ REDO

⟲ UNDO

Başlangıç ▲ tc (Checkpoint) ▲ tf (Çökme)

T1 — Dahil Edilmez
Checkpoint öncesi tamamlandı. Değişiklikler zaten diske yazıldı.

T2 & T4 — REDO
Commit edildi ama diske yazılmamış olabilir. Yeniden uygulanır.

T3 & T5 — UNDO
Commit edilmedi, kısmen yazılmış. Geri alınır.

08 — Veri Birimi Boyutu

Data Item Granularity

Recovery Manager'ın log kayıtlarında kullandığı veri biriminin boyutuna granularity (taneciklilik) denir. Boyut arttıkça daha az kayıt gerekir ama her kayıt daha büyük olur.

Granularity Seviyesi	Açıklama	Log Kayıt Sayısı	Kayıt Boyutu	Kullanım Yeri
Değer (Value)	Tek bir alan değeri	Çok fazla	Çok küçük	Küçük, sık güncellenen veriler
Kayıt (Record)	Bir tablo satırı	Orta	Orta	Genel amaçlı
Blok/Sayfa (Block)	Bir disk bloğu (genellikle 4KB-16KB)	Az	Büyük	SimpleDB gibi basit sistemler
Dosya (File)	Tüm bir dosya	Çok az	Çok büyük	Toplu işlemler, yedekleme

⚖️

Trade-off: Büyük granularity → daha az log kaydı, daha büyük kayıtlar. Küçük granularity → daha fazla kayıt, daha ince kontrole sahip geri alma. Recovery Manager'ın bu seçimi performans üzerinde doğrudan etkilidir.

Recovery Manager'ın Tasarım Kararları

Recovery Algoritması Seçimi Undo-Redo, Undo-Only veya Redo-Only algoritmalarından biri seçilir. Her biri farklı buffer yönetimi gerektirir.

Granularity Kararı Value-level, block-level veya file-level granularity kullanılacağı belirlenir.

Checkpoint Stratejisi Quiescent (basit, kesintili) veya Nonquiescent (karmaşık, kesintisiz) checkpoint yöntemi seçilir.

Özet: Transaction Yönetiminin Temelleri

Veritabanı bütünlüğü, iyi tasarlanmış transaction yönetimi ile korunur. ACID özellikleri hedefi, Recovery Manager ve WAL mekanizması ise bu hedefe ulaşmanın yoludur.

ACID Atomicity Consistency Isolation Durability Recovery Manager Log Kayıtları Rollback Undo-Redo Write-Ahead Logging Quiescent Checkpoint Nonquiescent Checkpoint Granularity

TransactionYönetimi