Merhaba değerli okurlar.
Bu makalemde sizlere transaction ile ilgili oldukça önemli konu olan Isolation Levels 'ı anlatacağım.Daha önceki makalelerimde transaction ı nasıl kullanacağımılass="r1 fiji-r1">
Öncelikle native yani tüm veri tabanı sistemlerinin kabul ettiği 4 adet isolation level lar vardır.Fakat MSSQL Server ise bize bunlara ek olarak 2 adet isolation level sağlamaktadır.
1-)Read Uncommited(level 0)
2-)Read Commited(level 1)
3-)Repeatable Read(level 2)
4-)Serializable(level 3)
Bunlara ek olarak Mssql in bizlere sağladıkları ise ;
1-)Read Commited Snapshot Isolation
2-)Snapshot Transaction Isolation
Yukarıdaki isolation level ları incelemeden önce ortak zamanlı erişim sorunlarını anlatmak istiyorum arkadaşlar.Nedir ortak zamanlı erişim sorunları?Aynı anda birden fazla transaction ın veya session ın aynı veri üzerine erişmek istemesi ve işlem yapmak istemesi sırasında ortaya çıkabilecek olan sorunlardır.4 adet sorun karşımıza çıkmaktadır.
1-) Lost Updates:Aynı anda birden fazla transaction aynı anda bir veri üzerinde güncelleme yapmak istediği zaman en son işlem yapan transaction ın kaydı geçerli olur.Bu yüzden veri kaybı yaşanır.
2-)Dirty Reads:Bir transaction ın bir veri üzerinde yapmış fakat commit etmemiş olduğu bilgileri diğer transaction tarafından gerçek kayıtmış gibi okuması durumudur.
3-)Non-Repeatable Reads:Bir transaction bir veriyi okusun ve kendi içinde işleme soksun.Bu transaction commit etmeden başka bir transaction bu veriyi okusun.Daha sonra işlem yapan transaction tekrar veriyi okumak istediğinde veri aynı veri olmayacağı için sorun yaşanmaktadır.
4-)Phantom Reads:Aynı anda çalışan transaction düşünelim.Bir transaction bir tablodaki verilerin tamamını çeksin ve kendi içindeki işleme soksun.Bu sırada da diğer transaction aynı tabloya veri ekleme işlemi yapsın.Daha sonra ilk transaction tekrar verileri çekmek istediğinde yeni eklenen veriler hayalet veri olarak görünür.
İşte tüm bu sorunlara çözüm olarak isolation level lar vardır.Hadi gelin şimdi onları inceleyelim arkadaşlar.
Bir veri üzerinde bir kullanıcı transaction yaparken diğer kullanıcılarında değişikliğe uğramış fakat commit edilmemiş verileri görebilmesini sağlayan level'dır.Bu durum bize performans sağlar fakat verimizin güvenliğini elimizden
alır neredeyse.Çünkü ya yapılan transaction commit edilmezse yani bir hata oluşur ve tüm yaptığı işlemleri rollback yaparsa ne olacak ? İşte bu durumda ortaya çıkan soruna Dirty Read denilir.Yani kısacası bir transaction i
İşte tüm bu sorunlara çözüm olarak isolation level lar vardır.Hadi gelin şimdi onları inceleyelim arkadaşlar.
Peki bu level ı nasıl kullanacağım ?
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Yukarıdaki gibi sql komutu ile oldukça basit bir şekilde aktif hale getirebiliriz.
Bu level da ise eğer bir veri üzerinde transaction uygulanıyorsa diğer transactionların bu veriye erişmesini engeller.Sql server'ın default level ı budur arkadaşlar.Daha önce denediniz mi bilmiyorum fakat eğer bir veri üzerinde bir tansaction işlemi yapılıyor ise sql server da o veriye erişim engellenir.Peki bu sırada diğer sorgular veya transactionlar ne olacak ? Veri üzerindeki transaction'ın sonlanmasını beklemekten başka hiç bir şansları yok :)Read Uncommited ın ortaya çıkardığı dirty read sorununu ortadan kaldırır.Fakat losts updates sorunu vardır.
Peki bu level ı nasıl kullanacağım ?
Diyelim ki bir transaction işlemleri arasında bir veriyi çekti ve işlem yapmaya başladı.İşlemini tamamlamadan yani commit edilmeden bir başka transaction veya kullanıcı o verideki değeri değiştirdi.Transaction işlemlerini yaparken tekrardan o veriyi okuyup değerini almak istedi.Eee veri eski veri değil. Doğal olarak transaction'ın işlemlerinin sonucu yanlış çıkacaktır.İşte bu sorunu ortadan kaldırmak için bu level kullanılmaktadır.Yani kısaca bir transaction tarafından kullanılan veri diğer transaction tarafından okunamaz.Fakat buradaki asıl amaç bir transaction tarafından okunan ve kullanılan verinin değiştirilmemesidir.Bu sayede dirty reads,lost updates,non-repeatables reads sorunları ortadan kalkar.Fakat phantom reads sorunu vardır.
Peki bu level ı nasıl kullanacağım ?
Veri ekleme,silme ve güncelleme yapan transaction boyunca veri erişime kapanır.Bu sayede hiç bir ortak zamanlı sorun ortada kalmaz.Fakat işlemler çok fazla birikir.Bu da bize performans sorunu yaşatır.
Peki bu level ı nasıl kullanacağım ?
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
Yukarıdaki gibi sql komutu ile oldukça basit bir şekilde aktif hale getirebiliriz.
Bu level da Read Commited level da oluşan Shared Lock durumu ortadan kalkar.Yani bir transaction bir veride güncelleme yaparken bir başka transaction bu veriyi okuyabilir.Bir transaction içerisinde kalmış ve commit edilmemiş verilerin tempdb veritabanına snapshot larını kaydeder.Böylece diğer transactionların verileri okuması sağlanmaktadır.
Kullanılabilmesi için database seviyesinde READ_COMMITTED_SNAPSHOT parametresinin "on" konumunda olması gerekmektedir.Default olarak "off" ayarlanıktır.
ALTER DATABASE Northwind SET READ_COMMITTED_SNAPSHOT ON
Olarak kullanılır.
Bir üstteki level dan tek farkı burada yapılan konfigurasyonun transaction bazında olmasıdır.
Kullanımında öncelikle database seviyesinde ayar yapılması gerekir.
ALTERSnapshot Transaction Isolation
Bir üstteki level dan tek farkı burada yapılan konfigurasyonun transaction bazında olmasıdır. Kullanımında öncelikle database seviyesinde ayar yapılması gerekir. Daha sonra ise transaction seviyesinde ayarlama yapılması gerekmektedir. SET TRANSACTION ISOLATION LEVEL SNAPSHOT Umarım faydalı olmuştur.Bir sonraki makalemde görüşmek dileğiyle.
DATABASE Northwind SET ALLOW_SNAPSHOT_ISOLATION ON
Koray Düzgün.
