Bu makalede MSSQL Server Lock Compatibility konusuna detaylı bir şekilde değinmiş olacağız. SQL Server’da kilitleme (locking), eşzamanlı çalışan işlemler arasında veri tutarlılığını sağlamak için kullanılır. Lock Compatibility (Kilitleme Uyumluluğu), bir işlemin aldığı kilidin, başka bir işlemin almak istediği kilitle uyumlu olup olmadığını belirler.
Eğer iki lock birbirine uyumluysa (compatible):
Her iki işlem de aynı anda kaynağa (satır, sayfa, tablo vb.) erişebilir. Hiçbir işlem beklemez, blocking (engelleme) yaşanmaz.
Örneğin, Shared (S) ve Intent Shared (IS) kilitleri uyumludur, yani aynı anda alınabilir.
Eğer iki lock birbirine uyumsuzsa (not compatible):
İkinci işlem, ilk işlemin kilidinin serbest bırakılmasını bekler. Yani, ikinci işlem blocking durumuna girer.
Örneğin, Exclusive (X) ve Shared (S) kilitleri uyumsuzdur, bu yüzden biri varsa diğeri beklemek zorundadır.
Eğer bekleme süresi çok uzarsa, SQL Server deadlock tespit mekanizmasını çalıştırabilir ve işlemlerden birini deadlock victim (kurban) olarak seçip iptal edebilir.
Şimdi örnek üzerinden daha iyi anlayalım:
Session 1 bir satıra Shared (S) lock koyuyor:
BEGIN TRANSACTION;
SELECT * FROM Musteriler WITH (HOLDLOCK); -- Shared Lock (S)Not: WITH (HOLDLOCK) = Bu sorgu sırasında aldığım paylaşım kilidini (shared lock), transaction bitene kadar bırakma demektir.
Session 2 aynı satıra Shared (S) lock koymaya çalışıyor:
BEGIN TRANSACTION;
SELECT * FROM Musteriler WITH (HOLDLOCK); -- Shared Lock (S)Yukarıdaki iki işlemleri ayrı sessionlarda çalıştırdıktan sonra sonuçlarımız dönmüş oldu. Dikkat ederseniz commit işlemi yapılmadı.
Session 3 aynı satırı güncellemeye çalışıyor (Exclusive X lock gerekiyor):
BEGIN TRANSACTION;
UPDATE Musteriler SET Bakiye = 5000 WHERE MusteriID = 1;
Resimde dikkat ederseniz 66. session_id’nin 63 numaralı sesion_id’yi beklediğini görmekteyiz. 71. session_id ise 66. session_id’nin execulese lock’ını beklemektedir.
Exclusive (X) ve Shared (S) uyumsuz olduğu için, İşlem 3 bekler (blocking).
– Eğer işlem 1 veya işlem 2 commit/rollback yapana kadar İşlem 3 çalışamaz.
– Eğer SQL Server bir deadlock tespit ederse, işlemlerden birini iptal eder.
Ayrıca delete ve Insert komutlarını çalıştırdığımda aşağıdaki bekleme türleri görülmektedir.
Bu yüzden kilitlerin uyumluluğunu bilmek, performans ve ölçeklenebilirlik açısından kritik öneme sahiptir.
LCK_M_RS_S: Bir range shared (RS_S) kilidi almak için bekliyor. Bu kilit türü, genellikle bir aralıktaki verilerin okunması sırasında kullanılır.
LCK_M_RIn_NL: Bir range insert kilidi almak için bekliyor ama NL (No Lock) modunda. Buradaki NL, aslında intent lock gibi çalışır; yani tabloya veri eklenmeden önce aralıkların kilitlenmesini ifade eder. Bu tür kilitler, genellikle unique index’e sahip bir tabloya INSERT yapılırken görülür. Çünkü SQL Server, eklenecek değerin mevcut aralıklarda olup olmadığını kontrol etmek zorundadır.
Bir başka örnek vermek gerekirse Transaction1-Transaction2 aynı tablo kolonu üzerinde update yapmak istediğinde Transaction 2 – Transaction 1 işleminin commit olmasını beklemektedir.
Sorgumuza select çektiğimizde sonucumuzun gelmediği ama select sorgumuzda WITH (NOLOCK) ifadesi sorgu sonucumuzun geldiğini görmüş olacağız.
Aşağıdaki örnekte ise herhangi bir satıra update yapıldığında son kullanıcı select çektiğinde güncellenen satır haricinde diğer satırları select sorgusunda görebilir.
Tablomuz satır üzerinde lock oluşturmuştur. Bu sebepten isolation level farketmeksizin veriler değişmektedir.
Şimdi insert komutuyla nelerin son kullanıcının neleri görüp göremeyeceğini görelim. Tablomuza insert işlemi gerçekleştirelim. Commit işlemi gerçekleştirmiyorum.
55. session id üzerine lock konulur. Kullanıcı başka bir oturumdan insert yapabilir. Select çekebilir. Sadece select çekilecek kilitli bölümün select cümlesinde olmaması gerekmektedir.
Lock Type sorgu ilk gittiğinde uygulanan lock türüdür.
Aşağıdaki sadece ilk bölümü açıklamak gerekirse bir tablo shared lock alındığında başka bir session ilgili tabloda update komutu çalıştırabilir.
Yukarıdaki iki işlem gerçekleşti uyumluluktan dolayı başka bir session ilgili tabloya select çektiği için sonuç dönmez.
Update satırı dışında başka bir satıra select çekince sorgu sonucumuz dönmektedir.
| Lock Type | Shared | Update | Exclusive | Intent Shared | Intent Exclusive | Shared with Intent Exclusive) |
| S (Shared) | Uyumlu | Uyumlu | Bloklar | Uyumlu | Bloklar | Bloklar |
| U (Update) | Uyumlu | Bloklar | Bloklar | Uyumlu | Bloklar | Bloklar |
| X (Exclusive) | Bloklar | Bloklar | Bloklar | Bloklar | Bloklar | Bloklar |
| IS (Intent Shared) | Uyumlu | Uyumlu | Bloklar | Uyumlu | Uyumlu | Uyumlu |
| IX (Intent Exclusive) | Bloklar | Bloklar | Bloklar | Uyumlu | Uyumlu | Bloklar |
| SIX (Shared with IX) | Bloklar | Bloklar | Bloklar | Uyumlu | Bloklar | Bloklar |
Read committed isolation levelde tablo okumalarında ister aynı satır olsun ister başka satır olsun birbirini engellemez. Shared lock’da bunu göstermektedir.
Bu tablo, hangi kilit türlerinin birbiriyle uyumlu olduğunu ve hangi durumlarda blocking (engelleme) yaşanabileceğini gösterir. Soldaki kolon ilk kilitlenmenin alındığı yapı olarak karşımıza çıkmaktadır.
Başka bir makalede görüşmek dileğiyle..
Dünya hayatı yalnızca bir oyun ve bir oyalanmadan başkası değildir. Korkup-sakınmakta olanlar için ahiret yurdu gerçekten daha hayırlıdır. Yine de akıl erdirmeyecek misiniz? En’am Suresi, 32. Ayet
