Locking - 2
Veri Objeleri (data item= datum) ile adlandırılan Rowidentifier, Key, Page, Extent, HoBT (Heap or B-Tree), Tablo, File (Veritabanı Dosyaları), uygulama, Metadata, Allocation Unit ve veritabanı gibi nesneler üzerinde locking politikaları tasarlanmıştır. İlk makalemin devamı olarak yazdığım bu makalemde ise Books Online’da yeni ulaştığım referansı da eklemek istedim[1]. Şimdi gelelim, bahsi geçen veri objelerinde locking politikalarını READ/WRITE bakış açısıyla değerlendirmeye:
Bir veri objesi ya okunur ya da üzerinde bir değişiklik gerçekleştirilir.
Bahsi geçen kaydı okuma (READ) işlemi ise, kötümser locking zamanlarından kalma datum’un diğer okuma işlemlerinden etkilenmemesi isteniyorsa Shared Lock(S) devreye girer ve CPU’ya ait kod parçacığı olan scheduler tarafından Lock’lanır, bu anlayacağınız üzere bazen Page bazen ise HoBT olabilir. Transaction boyunca, Shared LOCK aktivitesini page üzerinde de görebilirsiniz, verinin üzerinde bulunduğu index üzerinde de görebilirsiniz.
Kullanılan algoritmayı ise basit manada, küçük hacimli datumdan büyüğe doğru en küçük çapta datum kilitleme şeklinde gözlemleyelebilirsiniz.
Yine, bahsi geçen kayıtta değişiklik işlemi ise bu scheduler tarafından yine kayıtta değişiklik yapılana kadar okumalara, locking’e karşı korunması istenir ve bu kez WRITE/READ senaryosu gerçekleşir ve datum üzerinde UPDATE(U) Lock’lar gözlemlenir. Burada yine şunu anlayabiliriz, bir transaction boyunca datum ile ilgili birden fazla çeşit Lock görülebilir. Bu süreç tamamen, ilk makalemden de anlayacağınız üzere tamamen concurrency başlığının en önde konularından biri ve süreğen olan bir kaç konudan biridir.
Şimdi gelelim WRITE/WRITE senaryosuna, bu defa da Exclusive LOCK’lar karşımıza çıkar. Modifiye edilen datum aynı anda değiştirilmek istenirse, bu kez kayıt yine korunur. READSET ve WRITESET’leri ile datum’un concurrency sürecinde olduğunu da ihmal etmezsek, datum üzerinde istenilen değişiklikler sırası ile gerçekleştirilebilir.
Pekte yabancısı olmadığımız Intent Lock’lar(IS, IX, SIX, IU, SIU, UIX) ise yukarıda bahsedilen işlemler süresince gerçekleşen lock’lardan korunmak için geliştirilen mekanızmalardır. Anlayacağınız üzere Lock’ı da Lock’la korumak icap eder. Buradaki amaç ise, bir page’in ait olduğu üst seviye fiziksel datum’u, kısacası; Extent’i etkilemek veya etkilememektir. Etkilenen Extent’in ise de HoBT’a karşı tavır almasını istememizdir.
READ/READ, WRITE/READ, WRITE/WRITE senaryolarına READ/WRITE da eklenmek istenirse ise bu işlemin lock’lar tarafından yönetilmemesine gerek olmadığını tahmin edebilirsiniz.
Schema Locks
Şu ana kadar değiştirilmek için korunan tüm fiziksel(physical) datum’ların nasıl lock’landığını inceledik, ilk makalemde bahsettiğim mantıksal objelerin lock’lanması ise schema lock’ları diye tanımlanan kavramı ortaya çıkarır. Burada ise mantıksal objenin durağan olması durumu ve değişikliğe uğraması durumu söz konusudur. Bu süreçte de Schema-Stability Lock ve Schema-Modification Lock tipi locking mekanizmaları mevcuttur. SQL Server Sorguları derlerken veya çalıştırırken, Stability-Lock; DDL üzerinde kimi değişikliklere karşı korumak için ise, Modification-Lock kullanır. Örneğin, SQL Server açısından DML olan TRUNCATE TABLE işlemi süresince, Schema-Modification lock koyulduğunu gözlemleyebilirsiniz.
Bulk Update Locks
Tüm DBMS’lerde tanımlı olan BULK operasyonlar vardır (ALTER INDEX REBUILD, gibi). Bunlardan birtanesi de BULK Update işlemleridir ve BULK INSERT cümlesi, OPENROWSET ile gerçekleştirilir. Aynı zamanda da bu cümlelerin bir opsiyonu olan TABLOCK hint’i belirtilmişse SQL Server Bulk Update Lock’ını devreye sokar.
Key-Range Locks
SQL Server, Serializible Izolasyon seviyesinde bir transaction kayıt kümesinden bazı satırları korumak istiyorsa da Key-Range Locking devreye girer. Anlayacağınız üzere mantıksal objeler olan Satırlar korunmak istenir. Satırlar üzerinde bulunan değerler ise başka transaction tarafından gerçekleştirilen okumalara karşı korunur. (Phantom Read’lere karşı korunur.)
Lock Compability
Devam eden transaction bir datum’u lock’lamış ve yeni bir transaction başka bir lock ile datum’un üzerinde işlem görüyor ise de girişte belirttiğim READ/WRITE bakış açısı devreye girer. Kısaca Lock’larında birbirilerine karşı davranış şekli vardır. Lock’ın release olması ile bir sonraki transaction’a karşı her tip lock ortaya çıkmaz.
Locking Hints[2]
Sorguları çalıştırırken SQL Server tarafından süreç boyunca kayıtların lock’landığını biliyorsak, kendimiz de bu sürece müdahil olabiliriz. Bu yüzden bir esneklik olarak tasarlanan ve storage engine’in davranışını değiştiren HINT’ler mevcuttur. Bunlar:
-
HOLDLOCK
-
NOLOCK
-
PAGLOCK
-
READCOMMITTEDLOCK
-
READPAST
-
ROWLOCK
-
TABLOCK
-
TABLOCKX
-
UPDLOCK
-
XLOCK
HOLDLOCK: Bir tablo veya view’e okuma yapıldığı anda yazmalara karşı korunması istenir.
UPDLOCK: Satır veya page seviyesinde yazma işlemlerinin okumalara karşı korunması istenirse kullanılır. TABLOCK ile kullanıldığında ise artık tablo seviyesinde okumalara karşı korunur.
NOLOCK: UPDLOCK’ın TABLOCK ile kullanıldığını düşünürsek, artık tablo okumalara karşı korunmuştur. NOLOCK ise bu durumun tam tersi bir koruma sağlar. Tablo seviyesinde okumalar, yazmalara karşı korunmuştur ve SELECT cümlenizin sonunda elinizde o anda SELECT süresince değişmiş veri değil, okumaya başladığınız andaki veri vardır.
PAGLOCK: SQL Server’ın en küçük birimi olan page’lere konulan lock’lardır. Sorguların çalışması sırasında default PAGLOCK hint’i ile çalışır. Multiversion concurrency’de ise snapshot’ı olan datum’lar için paglock size bazı şeyler ifade eder.
READPAST: Bu hint ile de satır seviyesinde konulan lock’lara aldırış edilmez ve okuma gerçekleştirilir. Tek başına READCOMMITTED izolasyon seviyesinde kullanılırken, SNAPSHOT izolasyon seviyelerinde kullanılamaz.
ROWLOCK: Alt seviyede bulunan page’de ve üst seviyede bulunan tabloda yer alan bir lock’a karşı yazma veya okuma işlemlerinde satırı korumak amaçlı kullanılır.
TABLOCK: Tablodaki veriyi koruma amaçlı kullanılır ve page ve satır seviyesinde okumayı sağlamak amaçlı shared lock koyulmasına yol açar.
TABLOCKX: TABLOCK’tan farkı yazmayı koruma amaçlıdır. Yani, tablo için bir Exclusive lock koyulması istenir.
XLOCK: Hem satır, hem page hem de tablo tutulmak isteniyorsa, bu hint’i kullanırız ve Exclusive lock konulmasını sağlar.
NOT
Özellikle iyimser Locking'den bahsediyorsanız, CHECKSUM kullanılarak iyimser locking politikaları tasarlanan DBMS'ler de görebilirsiniz. Fakat bunun için yine Snapshot kullanılacak şekilde tasarlanmış olduklarını unutmamanız gerekir.
SONUÇ
Locking’in SQL Server tarafından gerçekleştirilen bir süreç olduğunu öğrenmiş olmakla birlikte, müdahaleleri de çözüme uygun tasarlamamız gerektiğini anlamış oluyoruz. Niye Exclusive Lock konulacağını kestirmekten ziyade bu konunun öğrenilmiş olunması, günlük işlerimizde yürüyen rutine bakış açımızı değiştirir