SQL Server Lock(Kilit) Çeşitleri
SQL Server, eş zamanlı gelen sorgu isteklerinin veriye nasıl erişeceğini belirleyen farklı lock çeşitleri uygular. Örneğin aynı kaydı bir kullanıcının okumak istediğini diğer kullanıcının değiştirmek istediğini düşünün.
Biri değiştirmeye çalışırken diğeri okuyabilecekmi? Ya da biri okurken diğer değiştirebilecek mi?
Lock çeşitleri ile ilgili detaylı bilgiyi aşağıdaki tabloda bulabilirsiniz. Lock çeşitlerinin davranış şekilleri isolation level seviyesine göre değişir. Isolation Level’ler ile ilgili detaylara aşağıdaki makalelerden erişebilirsiniz.
Aşağıdaki lock çeşitlerinden hangi lock çeşidinin hangi lock çeşidini engelleyeceği ya da engellemeyeceği bilgisine “Lock Compatibility Nedir” isimli makalemden erişebilirsiniz.
Shared (S) Lock |
Sadece veri okunurken konan lock çeşididir. Örneğin Select. Veri okuma işlemi biter bitmez lock bırakılır. En masum ve en az sıkıntıya sebep olan lock çeşidi diyebilirim. Genellikle kimse bu lock’ın koyulduğunu bile hissetmez.
Shared Lock pessimistic concurrency control’de bir kaydın eş zamanlı birden fazla session tarafından select edilmesine izin verir. “Optimistic ve Pessimistic Concurrency Control Nedir” isimli makalemi okumak isteyebilirsiniz. |
Update (U) Locks |
Deadlock problemini engellemek için koyulan bir lock çeşididir. Aynı anda aynı kaynağa sadece bir transaction Update Lock koyabilir. Transaction, update yapacağı anda Update Lock’ı Exclusive Lock’a dönüştürür. |
Exclusive (X) Locks |
Kaynağı neredeyse tamamen lock’layan lock çeşididir. Bu lock koyulduğunda başka hiçbir transaction o kaynağı değiştiremez. Sadece WITH(NOLOCK) hinti olan select cümlecikleri bu kaynağa erişebilir. WITH(NOLOCK) select ifadelerinin sonuna konan ve select’in isolation seviyelesinin READ UNCOMMITTED gibi çalışmasını sağlayan bir hinttir. Isolation Seviyeleri ile ilgili makalenin başında paylaştığım linklerden bilgi edinebilirsiniz. |
Intent Locks |
Bir kaynakta bir lock varsa ve başka bir transaction bu kaynağa lock koymak istiyorsa fakat lock koyan ilk transaction’ın koyduğu lock tipi ile ikinci transaction’ın lock tipi uyumlu değilse ikinci transction’ın ilk lock’ın bitmesini beklemek zorunda olduğunu daha önce söylemiştik. Fakat beklerken intent lock koyarak bir sonraki lock koyacak transaction’ın kendisi olduğunu belirtir ve diğer transaction’ların lock koymasını engeller.
Birkaç tipi vardır:
Intent Shared (IS): Şu an lock’lı durumda olan kaynaktan bir kısmını okuyacağını belirten lock tipidir. Lock bittiğinde Shared Lock koyarak ihtiyacı olan veriyi okur. Shared Lock koyduğunda Intent Shared Lock’ı kaldırmaz. İşi bittiğinde iki lock türünü beraber kaldırır.
Intent Exclusive (IX): Şu an lock’lı durumda olan kaynaktan bir kısmını değiştireceğini belirten lock tipidir. Lock bittiğinde Exclusive Lock koyarak ihtiyacı olan veriyi değiştirir. Exclusive Lock koyduğunda Intent Exlusive Lock’ı kaldırmaz. İşi bittiğinde iki lock türünü beraber kaldırır.
Shared With Intent Exlusive (SIX): Şu an lock’lı durumda olan kaynağın tamamını okuyacağını ve bir kısmını değiştireceğini belirten lock tipidir. |
Schema |
Şema üzerinde bir işlem olduğunda koyulan lock çeşididir. |
Bulk Update (BU) |
Bir tabloya bulk kopyalama işlemi tablock hinti ile birlikte yapıldığında koyulan lock çeşididir. |
Key-range |
Serializable transaction isolation level kullanıldığında, bir sorgu select çekerse, select çektiği satır aralığını lock’layan lock çeşididir. |
Aşağıdaki komut yardımıyla veritabanı üzerindeki lock’ları görebilirsiniz. Request Status kısmında GRANT ya da WAIT yazar. GRANT yazıyorsa transaction o lock’ı koymuş demektir. WAIT yazıyorsa bu lock’ı koymak için bekliyor demektir.
SELECT OBJECT_NAME(p.OBJECT_ID) AS TableName, resource_type, resource_description,request_mode,request_status,request_session_id FROM sys.dm_tran_locks l JOIN sys.partitions p ON l.resource_associated_entity_id = p.hobt_id WHERE l.resource_database_id = DB_ID()