Snapshot Isolation Nedir?

Bu flood’da SQL 92 standardında olmayan ancak günümüzde popüler olarak kullanılan Snapshot Isolation’a, izolasyonların şahına değinelim.

Hatırlarsanız Dirty Read, Phantom Read ve Nonrepetable Read olaylarından kaçınmak için elimizde sadece Serializable izolasyon seviyesinin olduğunu fakat bunun da RDBMS’in concurrency’sini düşürdüğü için ölçeklenebilirlik ve dolaylı olarak da performans problemine yol açtığını söylemiştik. Snapshot Isolation, Serializable’ın sağladığı izolasyonun aynısını sağlar hem de ölçeklenebilirlik problemine yol açmadan.

Bu cümleye çok sevinmeden okumaya devam etmenizi öneririm :-) Snapshot Isolation adından da anlaşılacağı gibi her bir transaction’a üzerinde çalışmak üzere ilgili kayıtların bir kopyasını sağlar, yani datanın snapshot’ı üzerinde çalıştırır, böylece her bir transaction tutarlı data üzerinde çalışmış olur. Tutarlı olarak anlık kullanıcı sayısı toplamını hesaplayan transaction ile yeni bir kullanıcı ekleyen transaction birbirlerini etkilemeden sağlıklı bir şekilde çalışırlar. Aynı kaydı iki transaction’ın güncellemek istediği durumunda ise ilk finalize olan transaction’ın Commit edilmesine izin verilir, ikinci transaction ise “Update Conflict” oluştuğu gerekçesi ile abort edilir.

İyi Mühendisler bir kalemden kaybetmeden başka bir kalemden kazanç sağlamanın mümkün olmadığını iyi bilir.

Snapshot Isolation kullanılırken Integrity sağlamak için diğer izolasyon seviyelerine göre çok çok dikkatli olmak gerekir. Normal izolasyon seviyelerinde Writer’lar tarafından bloklanan Reader’lar dolayısıyla üzerinde kafa yormadığımız konular Snapshot’ta Writer’lar tarafından bloklanmayan Reader’lardan dolayı tam bir baş belası olur.

Son olarak MS SQL Server gibi kimi üreticiler Read Committed Snapshot adlı yeni bir izolasyon seviyelerini destekleyerek kimisi de SELECT cümlelerine FOR UPDATE takısını ekleyerek kullanıcılarını bu problemlerden uzak tutmaya çalışırlar.