ACID ve Transaction İzolasyonu: PostgreSQL, MySQL ve SQL Server Karşılaştırması

Test edilen: PostgreSQL 16.15 ve 17.11 · MySQL 8.4.11 (InnoDB) · SQL Server 2022 Ortam: Docker / dxlab, tek düğüm; senaryoların yaptığı ayar değişiklikleri aşağıda belirtilmiştir. Etkin ayarların tamamı kaydedilmemiştir. Seviye: Orta - İleri · Kapsam: Kavramsal rehber ve karşılaştırmalı laboratuvar gösterimleri

Kısa Özet

•"REPEATABLE READ" adı üç motorda aynı garantiyi vermez. Sağlanan iki oturumlu deney kayıtlarında PostgreSQL ve MySQL'de *phantom yok ama write skew var*; SQL Server'da *phantom var ama (bu senaryoda) write skew yok, onun yerine deadlock var*.
•Varsayılan seviye motora göre değişir: PostgreSQL ve SQL Server READ COMMITTED, MySQL InnoDB REPEATABLE READ.
•`READ UNCOMMITTED` istemek, dirty read almak demek değildir. PostgreSQL bu seviyeyi READ COMMITTED gibi çalıştırır; MySQL ve SQL Server'da dirty read gerçekten olur.
•Bu CHECK ihlali deneyinde hata sonrasında gönderilen `COMMIT`, farklı sonuçlar verdi. PostgreSQL’de önceki değişiklik kalmadı; MySQL ve SQL Server’da ilk başarılı UPDATE kalıcı oldu. Bu sonuç, bütün hata türlerine genellenemez.
•SQL Server’da RCSI, sıradan `READ COMMITTED` okumalarının satır değişiklikleri nedeniyle beklemesini azaltabilir. Deneyde OFF iken okuma zaman aşımına uğradı; ON iken önceki commit edilmiş değer okundu. RCSI, işlem boyunca aynı snapshot veya tamamen kilitsiz çalışma garantisi değildir.

> Kanıtın kapsamı Sonuçlar, yazarın sağladığı dxlab çıktılarından aktarılan kayıtlardır. Bu editoryal çalışmada laboratuvar yeniden çalıştırılmadı. Her senaryo tek çalıştırmaya dayanır; performans karşılaştırması veya bütün zamanlamalar için garanti değildir. JSON kayıtları tam istemci günlükleri değil, komut metinleri ve özet çıktı satırlarıdır. Kanıt paketini indirin.

1. Temel Sorun: Eşzamanlılık ve Doğruluk Arasındaki Gerilim

Bir ödeme, rezervasyon veya stok işlemi birden fazla SQL ifadesinden oluşabilir. Bu ifadelerin bir iş birimi olarak tamamlanması, eşzamanlı işlemlerle doğru etkileşmesi ve commit sonrasında beklenen hata koşullarına dayanması gerekir. ACID bu gereksinimleri dört ayrı başlıkta ele alır. Güçlü izolasyon, iş yüküne göre kilit beklemesi, sürüm saklama veya yeniden deneme maliyeti getirebilir; maliyetin büyüklüğü bu laboratuvarda ölçülmedi.

ACID, bu gerilimin sözleşmesidir:

Harf	Garanti	Hangi mekanizmaya dayanır
Atomicity	İşlem ya tümüyle uygulanır ya hiç uygulanmaz	Geri alma mekanizması
Consistency	İşlem, tanımlı kuralları (kısıt, tetikleyici) bozmadan bir geçerli durumdan diğerine geçirir	Kısıtlar + uygulama mantığı
Isolation	Eşzamanlı işlemlerin birbirini nasıl görebileceği ve etkileyebileceği seçilen seviyenin kurallarıyla sınırlanır	Kilitleme ve/veya çok sürümlü okuma (MVCC)
Durability	Başarılı commit, seçilen dayanıklılık ve depolama koşulları kapsamında korunur	Kalıcı bir işlem günlüğü (WAL/redo log)

Bu makalenin ağırlığı izolasyon üzerindedir; ancak atomiklik, tutarlılık ve dayanıklılık da ayrı değerlendirilmelidir. İzolasyon tek yapılandırılabilir özellik değildir: örneğin PostgreSQL’de asenkron commit, başarı yanıtı ile kalıcı WAL yazımı arasındaki zamanlamayı değiştirir. Asenkron commit belgesi

•Atomiklik: Uygulamanın tek iş saydığı adımları doğru transaction sınırına koyun; hata sonrasında commit/rollback kararını açık yönetin.
•Tutarlılık: CHECK (balance >= 0) tek satırın bakiyesini korur. İki satırın toplamına ilişkin bir iş kuralını kendiliğinden tanımlamaz.
•İzolasyon: Birden fazla okumanın aynı görünümü kullanıp kullanmadığını ve eşzamanlı yazıların nasıl çatışacağını belirleyin.
•Dayanıklılık: Commit onayının hangi arıza modelinde korunacağını değerlendirin. Tek düğümde kalıcılık, yüksek erişilebilirlik veya yedekten kurtarılabilirlikle aynı şey değildir.

ℹ️ Not: Consistency'nin özel durumu "C" harfi diğer üçünden farklıdır: veritabanı yalnızca *tanımladığınız* kuralları koruyabilir. Aşağıdaki write skew örneğinde, "toplam bakiye en az 100 olmalı" kuralını veritabanı bilmez; bu bir uygulama kuralıdır ve izolasyon yetersizse sessizce bozulur.

2. İzolasyon Anomalileri: Neyi Engellemeye Çalışıyoruz?

Aşağıda dört pratik olguyu inceliyoruz. Seviye tablosundaki daha genel serialization anomaly, başarılı işlemlerin sonucunun hiçbir seri yürütme sırasıyla açıklanamamasıdır; write skew bunun bir örneğidir.

Anomali	Ne olur	Tek cümlede
Dirty read	Başkasının commit edilmemiş değişikliğini okursunuz	Sonradan geri alınabilecek veriye güvenmek
Nonrepeatable read	Aynı satırı iki kez okursunuz, farklı değer gelir	Transaction içinde veri "değişir"
Phantom read	Aynı sorguyu iki kez çalıştırırsınız, satır kümesi değişir	Yeni satır "belirir"
Write skew	İki işlem ayrı satırları günceller, ama birlikte bir kuralı bozar	Her biri tek başına doğru, ikisi birlikte yanlış

Standart seviye-anomali tablosu (S1, PostgreSQL dokümanından) şöyledir:

Seviye	Dirty read	Nonrepeatable read	Phantom read	Serialization anomaly
Read uncommitted	Mümkün	Mümkün	Mümkün	Mümkün
Read committed	Yok	Mümkün	Mümkün	Mümkün
Repeatable read	Yok	Yok	Mümkün	Mümkün
Serializable	Yok	Yok	Yok	Yok

⚠️ Uyarı: Bu tablo bir alt sınırdır Standart, hangi anomalilerin mutlaka engellenmesi gerektiğini söyler; bundan *fazlasını* engellemeyi yasaklamaz. Dokümanın kendi ifadesiyle PostgreSQL'in Repeatable Read'i phantom'a izin vermez ve bu standarda uygundur (S1). Sonuç: aynı seviye adı, motorlar arasında farklı *üst* garantiler verebilir, ve aşağıdaki ölçümler tam olarak bunu gösterir.

3. Motorlar Neden Farklı Davranır? İki Mimari Aile

İzolasyonu uygulamanın iki temel yolu vardır, ve çoğu fark buradan gelir.

Kilit tabanlı (SQL Server varsayılan modu): Okuyucu *paylaşımlı kilit* alır, yazar *özel kilit* alır; biri diğerini bekler. Anomali engellemek = daha uzun süre kilit tutmak. Bedel: bekleme ve deadlock.

Çok sürümlü (MVCC; PostgreSQL, MySQL InnoDB, SQL Server'da RCSI/SNAPSHOT): Sıradan sürümlü okuma, uygun bir *anlık görüntüden (snapshot)* okuyabilir ve yazarın satır değişikliği kilidini beklemeyebilir. Açık kilitleyen okumalar, DDL ve şema kilitleri gibi durumlar yine bekleme yaratabilir. Yazar yeni sürüm üretir. Bedel: eski sürümlerin temizliği ve bazı seviyelerde çakışmada iptal (yeniden deneme).

	PostgreSQL	MySQL InnoDB	SQL Server
Varsayılan seviye	Read Committed (S1)	Repeatable Read (S2)	Read Committed (S3)
Okuma mekanizması (varsayılan)	MVCC snapshot	MVCC snapshot (tutarlı okuma)	Paylaşımlı kilit (RCSI kapalıyken)
MVCC ek seçeneği	Zaten MVCC	Zaten MVCC	`READ_COMMITTED_SNAPSHOT`, `SNAPSHOT`
Serializable'ın uygulanışı	SSI (engelleyici olmayan predicate izleme; gerekli durumda iptal)	Açık transaction / autocommit kapalı bağlamında düz SELECT için örtük `FOR SHARE` (S2)	Aralık kilitleri

ℹ️ Not: SSI ne demek PostgreSQL'in Serializable'ı, Snapshot Isolation üzerine *serileştirme anomalisi denetimi* ekleyen SSI (Serializable Snapshot Isolation) tekniğidir. Doküman, bu seviyedeki "predicate lock"ların bloklamaya yol açmadığını ve bu yüzden deadlock üretemeyeceğini belirtir (S1). Bu özellik yalnızca SSI predicate izleme mekanizması için geçerlidir. Aynı transaction içindeki normal satır ve tablo kilitleri bekleme ve deadlock üretebilir; her eşzamanlı çakışma da serialization failure doğurmaz.

4. Test Ortamı ve Yöntem

Tüm deneyler iki veya üç eşzamanlı oturumla, her deney öncesi sıfırlanan bir tabloda yapıldı. Aşağıdaki şema kavramsaldır; motorlara özgü kurulum komutları kanıt paketindedir:

sql

CREATE TABLE accounts(
  id      INT PRIMARY KEY,
  owner   VARCHAR(20),
  balance INT CHECK (balance >= 0)
);
-- Her deneyden önce:  (1,'ali',100), (2,'veli',100)

	PostgreSQL	MySQL	SQL Server
Sürüm	16.15 ve 17.11	8.4.11	2022 (16.x)
Kaydedilen başlangıç bilgisi	Read Committed	Repeatable Read	RCSI OFF, izolasyon kodu 2; deneyler ayrıca ayar değiştirir
İstemci	`psql`	`mysql`	`sqlcmd`

Yöntem notları (sonuçları yorumlarken önemli):

•Zamanlama sleep/pg_sleep/WAITFOR DELAY ile sağlandı. Bu, bir gösterim için yeterlidir; milisaniye ölçeğinde yarışları kanıtlamaz.
•"Bekleme süresi" ölçümleri saniye çözünürlüklüdür; "yaklaşık 2 sn" okuyun, kesin değer olarak değil.
•PostgreSQL 16.15 ve 17.11 için bildirilen davranış sonuçları aynı çıktı; aşağıda ayrı belirtilmedikçe "PostgreSQL" ikisini birlikte ifade eder.
•Her deney, kurulumu sıfırlayıp tek bir senaryo çalıştırır. Her deney bir kez koşturuldu (tekrar sayısı 1); varyans ölçülmedi.
•Senaryo kodları, iki oturumun işlem sırası ve her düğümün aktarılmış özet çıktısı kanıt dizininde verilmiştir; tam hata akışları ve oturum transkriptleri pakette yoktur. Etkin oturum ayarlarının (ör. XACT_ABORT, autocommit, kilit zaman aşımları) tam kaydı bu sürümde eksiktir; bkz. kanıt paketindeki EK-A.md / A.1.

5. Atomiklik: Hata Olunca Ne Geri Alınır?

Senaryo: Bir transaction içinde iki UPDATE. İkincisi CHECK (balance >= 0) kısıtını ihlal eder (veli'den 500 düşmeye çalışıyoruz). Sonra uygulama COMMIT der.

Aşağıdaki kasıtlı hatalı akış, kavramsal karşılaştırma içindir; uygulamada hata alındığında commit etmeye devam etmeyin. Test şeması ve başlangıç satırları önce hazırlanmalıdır.

sql

-- PostgreSQL
BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
UPDATE accounts SET balance = balance - 500 WHERE id = 2;
COMMIT;

sql

-- MySQL / InnoDB
START TRANSACTION;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
UPDATE accounts SET balance = balance - 500 WHERE id = 2;
COMMIT;

sql

-- SQL Server: OFF bu açıklayıcı örnek için açık seçilir.
-- Orijinal çalıştırma bu ayarın etkin değerini kaydetmedi.
SET XACT_ABORT OFF;
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
UPDATE accounts SET balance = balance - 500 WHERE id = 2;
COMMIT;

İstemci davranışı da önemlidir: orijinal PostgreSQL akışı ON_ERROR_STOP kullanmaz; MySQL akışı --force ile hatadan sonra devam eder. Sürücünüz SQL hatasından sonra sonraki ifadeleri göndermiyorsa aynı sonuç akışını beklemeyin.

E1a — Bildirilen sonuç:

Motor	Hata sonrası `COMMIT` → bakiyeler (ali, veli)
PostgreSQL	100, 100 (değişiklik kalmadı)
MySQL 8.4	50, 100 (ilk UPDATE kalıcı)
SQL Server 2022	50, 100 (ilk UPDATE kalıcı)

Aynı senaryoda hatayı yakalayıp `ROLLBACK` diyen uygulama her üç motorda da 100, 100 ile sonuçlandı (E1b). *Sınır:* SQL Server'da bu adım TRY/CATCH ile, diğer ikisinde düz ROLLBACK ile yazıldı; komut şekilleri birebir aynı olmadığından üçünün karşılaştırması sınırlıdır (kanıt paketindeki EK-A.md / A.3).

Bu atomiklik ihlali değildir. Hatalı ifadeyi geri alıp kalan başarılı ifadeleri açıkça commit etmek ile uygulamanın bütün iş birimini geri almak farklı kararlardır. Bu CHECK senaryosunda PostgreSQL’in hatalı transaction’ı normal akışta devam edemez; COMMIT önceki değişikliği kalıcılaştırmamıştır. Savepoint ile kontrollü hata kurtarma ayrı bir tasarımdır.

MySQL’de her hata yalnızca ifadeyi geri almaz: deadlock bütün transaction’ı geri alabilir. SQL Server’da da etki hata türüne ve XACT_ABORT ayarına bağlıdır. MySQL hata yönetimi, SQL Server XACT_ABORT

Uygulama ilkesi: İş birimi başarısızsa açık transaction’ı geri alın, bağlantıyı temiz durumda havuza döndürün ve gerekiyorsa bütün iş birimini yeniden deneyin. Dış sistemde ödeme veya bildirim gibi yan etkileri körlemesine tekrar etmeyin. Savepoint gibi yöntemler ancak iş kuralı kısmi devamı açıkça kabul ediyorsa kullanılmalıdır.

6. İzolasyon: Anomaliler Üzerinden Karşılaştırma

▸6.1 Dirty read: `READ UNCOMMITTED` ne zaman gerçekten dirty?

Senaryo: Oturum B bir satırı 0 yapar ve commit etmez. Oturum A, READ UNCOMMITTED seviyesinde aynı satırı okur. Gerçek (commit edilmiş) değer 100.

E2 — Bildirilen sonuç:

Motor	A'nın okuduğu	Dirty read?
PostgreSQL	100	Hayır
MySQL 8.4	0	Evet
SQL Server 2022	0	Evet

PostgreSQL dokümanı bunu açıkça belirtir: Read Uncommitted modu Read Committed gibi davranır (S1). MySQL dokümanı, READ UNCOMMITTED'da SELECT'lerin kilitsiz çalıştığını ve "satırın önceki bir sürümünün kullanılabileceğini", bunun dirty read olduğunu söyler (S2). SQL Server'da READ UNCOMMITTED, paylaşımlı kilit almaz ve özel kilitlerle de engellenmez (S3).

NOLOCK notu: Microsoft belgesi READ UNCOMMITTED ile bütün SELECT tablolarına NOLOCK uygulamasını okuma etkisi açısından eşdeğer açıklar. Bu, bütün şema kilitlerinden kurtulmak anlamına gelmez. NOLOCK bu pakette ayrıca denenmedi; dirty read kabulü gerektirdiğinden genel raporlama çözümü olarak sunulmamalıdır. (S3)

▸6.2 Nonrepeatable read: `READ COMMITTED` ve `REPEATABLE READ`

Senaryo: A bir satırı okur, 3 sn bekler, tekrar okur. Arada B aynı satırı 150 yapıp commit eder.

E3a / E3b — Bildirilen sonuç:

Seviye	PostgreSQL	MySQL 8.4	SQL Server 2022
READ COMMITTED	100 → 150	100 → 150	100 → 150
REPEATABLE READ	100 → 100	100 → 100	100 → 100

REPEATABLE READ satırındaki görünür sonuç üç motorda aynı, ama mekanizma farklıdır:

•PostgreSQL ve MySQL REPEATABLE READ deneyinde A, ilk okumada oluşan *snapshot*'tan okumaya devam eder. Bu deneyde B’nin UPDATE’i beklemeyi gerektirmeyen ayrı bir yazı olarak ilerledi. Bu ifade MVCC altındaki bütün yazılar için geçerli değildir.
•SQL Server'da REPEATABLE READ, A'nın okuduğu satıra paylaşımlı kilit koyar ve transaction bitene kadar tutar. B'nin UPDATE'i bu yüzden yaklaşık 2 sn bekledi (E3b'de ölçülen B_update_bekleme_sn=2). Aynı senaryoda READ COMMITTED iken B beklemedi (0).

Aynı "tekrarlanabilir okuma" garantisinin bedeli, kilit tabanlı motorda başkasının beklemesi, MVCC motorlarında eski sürümlerin tutulmasıdır.

▸6.3 Phantom read: Aynı seviye adı, farklı garanti

Senaryo: A SELECT COUNT(*) çalıştırır (2), 3 sn bekler, tekrar çalıştırır. Arada B yeni bir satır ekleyip commit eder.

E4 / E4b — Bildirilen sonuç:

Seviye	PostgreSQL	MySQL 8.4	SQL Server 2022
REPEATABLE READ	2 → 2 (phantom yok)	2 → 2 (phantom yok), B beklemedi	2 → 3 (phantom var), B beklemedi
SERIALIZABLE	2 → 2	2 → 2, B yaklaşık 2 sn bekledi	2 → 2, B yaklaşık 2 sn bekledi

Bu örnek şu ayrımı görünür kılar: `REPEATABLE READ` seviyesinde SQL Server phantom'a izin verir, PostgreSQL ve MySQL (düz SELECT için) vermez. SQL Server dokümanı bunu doğrular: Repeatable Read'de "diğer transaction'lar, mevcut transaction'ın arama koşuluna uyan yeni satırlar ekleyebilir ... bu da phantom read ile sonuçlanır" (S3).

SERIALIZABLE'da fark mekanizmadadır:

•SQL Server: "Diğer transaction'lar, okunan anahtar aralığına düşecek yeni satırlar ekleyemez" (S3). B'nin INSERT'i bekler.
•MySQL: InnoDB, autocommit kapalıyken düz SELECT'leri örtük olarak SELECT ... FOR SHARE'e çevirir (S2). B'nin INSERT'i yine bekler.
•PostgreSQL: SSI predicate izleme, SQL Server’daki gibi engelleyici aralık kilidi değildir. B’nin INSERT süresi PostgreSQL kaydında ölçülmedi; bu nedenle burada “0 saniye” sonucu çıkarılamaz. (S1)

▸6.4 Write skew: Her işlem doğru, birlikte yanlış

Write skew, satır düzeyindeki kısıtlar geçerli kalırken satırlar arası bir iş kuralını bozabilir. Yeterli koruma yoksa hata mesajı üretmeden gerçekleşebilir.

Senaryo (uygulama kuralı: toplam bakiye ≥ 100): Başlangıçta ali=100, veli=100 (toplam 200). İki oturum aynı anda toplamı okur (200 görür), kuralın sağlanacağını varsayar ve farklı satırlardan 60 düşer. Birlikte toplam 80 olur ve kural ihlal edilir.

sql

-- Sözde kod: tam yürütme sırası ve motor sözdizimi kanıt paketindedir.
-- Önce her oturumda seçilen izolasyon ile transaction başlatılır.
-- Her iki oturum:
SELECT SUM(balance) FROM accounts;          -- 200 görür
-- (kural: düşüşten sonra >= 100 kalmalı; 200-60=140 uygun görünür)
-- Oturum A:
UPDATE accounts SET balance = balance - 60 WHERE id = 1;
-- Oturum B:
UPDATE accounts SET balance = balance - 60 WHERE id = 2;
COMMIT;

Yazılan satırlar farklıdır; sorun aynı satırdaki bir güncellemeyi kaybetmek değil, iki ayrı kararın birlikte toplam kuralını bozmasıdır. Kilit tabanlı okumalar yine de bu işlemleri birbirleriyle çatıştırabilir.

E5a / E5b / E5c — Bildirilen sonuç:

Seviye	PostgreSQL	MySQL 8.4	SQL Server 2022
REPEATABLE READ	İkisi de commit → toplam 80, kural ihlal	İkisi de commit → toplam 80, kural ihlal	Deadlock, biri iptal → toplam 140, kural korundu
SERIALIZABLE	Serialization hatası bildirildi → toplam 140	Biri deadlock → toplam 140	Biri deadlock → toplam 140
SNAPSHOT adlı seviye	Bu isimde ayrı seviye yok	Bu isimde ayrı seviye yok	İkisi de commit → toplam 80, kural ihlal

Okuma (her sonuç tek çalıştırmadır; iki oturumun tam eşzamanlı başlamasını bu deney garanti etmez, yalnızca 3 sn'lik bekleme ile çakışmayı olası kılar):

1PostgreSQL ve MySQL'de `REPEATABLE READ` write skew'e izin verir. İkisi de snapshot tabanlıdır; her oturum kendi snapshot'ında 200 görür ve farklı satırları yazar. PostgreSQL dokümanı bu seviyenin Snapshot Isolation ile uygulandığını söyler (S1).
2**SQL Server'ın REPEATABLE READ'i bu senaryoda write skew'i *önledi*, ama kilitle:** her iki oturum okudukları satırlarda paylaşımlı kilit tuttu, ikisi de yazmaya çalışınca karşılıklı beklemeye girdi → deadlock. Bu "doğruluk için bekleme/iptal ödemek"in tipik örneğidir. Not: aynı sonuç, erişim yoluna (indeks varlığı, sorgu planı) göre değişebilir; tek senaryodan genelleme yapmayın.
3SQL Server `SNAPSHOT`, PostgreSQL `REPEATABLE READ` ile aynı anomaliyi gösterdi: ikisi de snapshot isolation. "Snapshot" adı "serializable" demek değildir.
4`SERIALIZABLE`, üç motorda da write skew'i engelledi, ama farklı bedelle: PostgreSQL serialization hatası, MySQL ve SQL Server deadlock.

Transaction hatasını ve yeniden denemeyi tasarlayın SERIALIZABLE veya PostgreSQL REPEATABLE READ kullanırken serialization failure / deadlock gibi hataları açıkça ele alın. İşlemi otomatik tamamlamak isteniyorsa yeniden deneme bütün transaction sınırından başlamalıdır; yalnızca son SQL ifadesini tekrarlamak yeterli değildir. Deneme sayısı sınırlı olmalı; dış yan etkiler ayrıca yönetilmelidir. Başarısızlığı kontrollü biçimde kullanıcıya döndürmek de bilinçli bir uygulama kararıdır. (S1)

7. SQL Server'a Özgü: `READ_COMMITTED_SNAPSHOT` (RCSI)

SQL Server’da RCSI kapalıyken, henüz commit edilmemiş aynı veriyi okumaya çalışan sıradan READ COMMITTED okuyucusu yazarın kilidini bekleyebilir. Bu, MVCC alışkanlığıyla gelen ekipleri şaşırtır.

Senaryo: A bir satırı günceller ve commit etmez (8 sn bekler). B aynı satırı READ COMMITTED ile okumaya çalışır (kilit zaman aşımı 3 sn).

E8a / E8b — Bildirilen sonuç:

`READ_COMMITTED_SNAPSHOT`	B'nin durumu	Süre
OFF (varsayılan)	Bloklandı, 3 sn sonra zaman aşımı (Msg 1222)	3 sn
ON	Beklemedi, commit edilmiş değeri (100) okudu	0 sn (saniye çözünürlüğü)

SQL Server dokümanına göre RCSI açıkken motor, her ifadeye "o ifadenin başlangıcındaki tutarlı bir snapshot" sunmak için satır sürümlemesi kullanır ve bu sıradan okumalar için satır/sayfa paylaşımlı veri kilitlerini kullanmaz; şema kilitleri gibi kilitler yine alınabilir (S3). RCSI, ifade düzeyinde görünüm sağlar. Bir transaction içindeki sonraki SELECT daha yeni commit edilmiş bir görünüm kullanabilir; transaction düzeyindeki SNAPSHOT ile eş anlamlı değildir. Aynı doküman, bu ayar bir *veritabanı seçeneği* olarak açılırken değişikliği yapan bağlantı dışında başka açık bağlantı olmaması gerektiğini söyler (S3); sağlanan senaryo bu değişikliği WITH ROLLBACK IMMEDIATE ile yapar, üretimde bunu kullanmak bağlantıları keser.

RCSI bir iş yükü kararıdır. Sürüm saklama, uzun okumalar ve uygulamanın bekleme varsayımları değerlendirilmelidir. SQL Server’da sürüm deposunun konumu ADR yapılandırmasına göre değişebilir; yalnızca “her zaman tempdb” varsayımıyla kapasite planlamayın. Bu pakette kaynak tüketimi ölçülmedi. Microsoft kilitleme ve satır sürümleme rehberi

8. Dayanıklılık: Yeniden Başlatma Ne Gösterir?

Test (E6): Sağlanan kayda göre veri yazılıp commit edildi; dxlab'ın kontrollü yeniden başlatma adımıyla düğüm yeniden başlatıldı; veri okundu. Her üç motorda değer korundu (777).

Bu bir çökme testi değildir Sağlanan kayıttaki işlem kontrollü bir yeniden başlatmadır. Durability'nin asıl iddiası, ani bir çökmeden (güç kaybı, süreç sonlandırma) sonra da commit edilmiş verinin kalmasıdır. Bu paket böyle bir arıza testini göstermez. Süreç çökmesi testi, host güç kaybı testi ve depolama arızası testi farklı arıza modelleridir. Container sürecini öldürmek tek başına gerçek güç kaybını veya diskin kalıcılık garantilerini kanıtlamaz. Ayrıca motorların günlük yazma/senkronizasyon ayarlarının "commit döndü" ile "diske yazıldı" arasındaki farkı belirlediği bilinir; bu ayarlar bu makalede incelenmedi ve ayrı bir makalenin konusudur.

9. Karar Rehberi: Seviyeyi İş Kuralından Başlayarak Seçin

1Önce bozulmaması gereken kuralı yazın. Tek satırın negatif olmaması ile farklı satırların toplamının bir eşiği koruması farklı problemdir.
2Gerekli görünümü seçin. Tek sorgu için tutarlı görünüm ile transaction boyunca tutarlı çoklu okuma aynı gereksinim değildir. SQL Server’da RCSI ikinci ihtiyacın doğrudan karşılığı değildir.
3Motorun gerçek davranışını kontrol edin. Bu laboratuvarda MySQL’in sıradan tutarlı okumaları ile kilitleyen okumaları aynı şey değildir; PG REPEATABLE READ ve SQL Server REPEATABLE READ de aynı mekanizmayı kullanmaz.
4İş kuralı seri yürütme gerektiriyorsa `SERIALIZABLE` ve hata yönetimini birlikte değerlendirin. Alternatif kilit veya veri modeli tasarımlarının doğruluğunu ayrıca test edin; bu pakette o alternatifler denenmedi.
5Okuma beklemesini azaltmak için kirli okumayı varsayılan çözüm yapmayın. SQL Server’da RCSI’yi uygulama davranışı ve kaynak maliyetiyle değerlendirin. MVCC motorlarında da açık kilitleme ve DDL beklemeleri mümkündür.
6Yeniden denemeyi sınırlayın. Retry edilebilir deadlock/serialization hatalarında bütün transaction’ı yeniden başlatın; sonsuz döngü kullanmayın. Dış yan etkiler ve belirsiz commit sonucu ayrıca ele alınmalıdır.

Bu laboratuvar bir performans yarışı değildir. “En hızlı motor” veya “her uygulama için en iyi seviye” sonucunu desteklemez.

10. Sık Yapılan Hatalar

1"REPEATABLE READ benim için phantom'u engelliyor." SQL Server'da engellemiyor (E4).
2"MVCC varsa write skew olmaz." Olur: PostgreSQL ve MySQL REPEATABLE READ'de bu paketin kayıtlarında görüldü (E5a).
3Hata yakaladığını sanıp `COMMIT` etmek. MySQL/SQL Server'da yarım iş bırakır (E1a).
4`SERIALIZABLE` açıp retry yazmamak. İptaller doğrudan kullanıcıya hata olarak yansır.
5`READ UNCOMMITTED` seviyesini "performans ayarı" saymak. MySQL ve SQL Server'da commit edilmemiş veri okur (E2).
6Motor değiştirirken izolasyon seviyesini adıyla taşımak. Aynı ad, aynı garanti değildir.
7RCSI'yi açarken kaynak maliyetini test etmemek (bu makalede ölçülmedi; bkz. Bölüm 7 uyarısı).

11. Kendiniz Tekrarlayın

Buradaki bildirilen deney sonuçları acid-pg16.yaml, acid-pg17.yaml, acid-mysql84.yaml ve acid-mssql2022.yaml senaryolarından üretildi; dosyalar kanıt paketindedir ve kodları kanıt paketindeki işlem sırasıyla uyumludur. Ortam kaydı dosyaları bu teslimde henüz çalıştırılmamıştır. Yeni çalıştırmada önce bu dosyaları kullanın; ayrıca deney bağlantısındaki etkin ayarları aynı oturumda kaydedin. Ayrı bir bağlantıdan alınan varsayılan ayar, deney oturumunun durumunu tek başına kanıtlamaz. Senaryolar sabit acidlab veritabanını oluşturabilir, var olan tabloları sıfırlayabilir ve sonunda veritabanını silebilir. Dosyalar dxlab’a özgü {node:...} ve {secret} yer tutucuları içerir; doğrudan terminal betiği değildir. Yalnızca test ortamında çalıştırın; E6 adımı düğümü yeniden başlatır.

12. Bir Sonraki Okuma

Kaynaklar ve Doğrulama Durumu

•[S1] PostgreSQL 17: Transaction Isolation. PostgreSQL 16 sonuçları ayrı sürüm kaydından gelir; 17 belgesi deney sürümünü yükseltme iddiası değildir.
•[S2] MySQL 8.4: InnoDB Transaction Isolation Levels.
•[S3] Microsoft: SET TRANSACTION ISOLATION LEVEL.
•[S4] MySQL 8.4: InnoDB Error Handling.
•[S5] Microsoft: SET XACT_ABORT.
•[S6] PostgreSQL 17: Transactions ve savepoint.
•[S7] PostgreSQL 17: Asynchronous Commit.
•[S8] Microsoft: Transaction Locking and Row Versioning Guide.

Doğrulama ayrımı: Deney sonuçları yazarın sağladığı kayıtlardır; mekanizma açıklamaları resmi belgelerle kontrol edilmiştir. Editoryal incelemede paket SHA-256 özetleri, YAML/JSON ayrıştırma ve komut metni eşleşmeleri kontrol edildi; veritabanları yeniden çalıştırılmadı. Eksik ortam bilgileri ve tek çalıştırma sınırı devam eder. Bir hata görürseniz contact@dataiotech.com adresine bildirin.