Locking - 1
SQL SERVER’DA LOCKING?
Concurrency denince aklımıza nasıl transactions’lar geliyorsa, Transactionların recover edilebilir olması RDBMS’ler için gereksinim oluşturur. COMMIT TRAN ve ROLLBACK TRAN cümlelerinin nasıl etki göstereceğini incelemişizdir. Transaction’ların geçmişlerini (history) ise belirli kriterlere göre incelediğimizde de Serializiblity kavramı ile tanışırız.
Bu makale serimde ise SQL Server’da COMMIT TRAN ve ROLLBACK TRAN cümlelerinden önce geçen Transaction’ların neden, nasıl ve hangi ilkeler doğrultusunda kayıtları; page’leri, ROWIdentifier’ları, Key’leri, Extent’leri, Tabloları veya veritabanlarını lock’ladığından bahsedeceğim.
Bu serinin sonunda da LOCKING HINT’leri daha kolay anlaşılır olacaktır.
LOCKS
Aynı kaynağa erişen (örneğin aynı page’e erişen) iki TRANSACTION olduğunu düşünürsek, bu transaction’lar ya READ-WRITE, ya WRITE-WRITE, ya WRITE-READ, ya da READ-READ şeklindedir. Bu şartları sürdürülebilir kılmak için ise LOCKING politikaları tasarlanmıştır. Özellikle Snapshot kavramının RDBMS’lerde concurrency için uyarlanması sonrası yukarıda bahsedilen koşullardan kimileri için RDBMS’in daha iyimser olması konuşulmuştur. SNAPSHOT kavramı SQL Server’ın Concurrency politikalarında yok iken RDBMS’in daha kötümser senaryolar üzerinde kurgulandığı söylenebilirdi.
Basit anlamda Snapshot, var olan kaydın (page, ROWIdentifier, Key, Extent, Tablo veya veritabanı) boş bir referansı şeklinde oluşturulur ve ancak değişiklikler için Snapshot kullanılır. Eğer elimizde boş referanslar var ise de SQL Server READ_COMMITTED_SNAPSHOT’ta ve ALLOW_SNAPSHOT_ISOLATION’da olduğu gibi Multiversion concurrency control tekniklerinden bahseder hale geliriz. READ_COMMITTED_SNAPSHOT ise SQL Server 2005’te duyurulmuştur.
Kötümser Locking(Pessimistic locking)
Bir kayıt, birden fazla transaction tarafından okunuyorsa veya yazılıyorsa (update ediliyorsa), bu kaydın diğer transaction’lardan korunması istenir, yani başına bir şey geleceği kabul edilir. Ve kayda bir lock koyulur. Kötümser denilmesinin sebebi budur.
Iyimser Locking (Optimistic Locking)
Bir kayıt, birden fazla transaction tarafından okunup, update ediliyorsa burada devreye o kaydın snapshot’ları girer ve concurrency snapshot’lar üzerinden sağlanır. Kısaca kaydın son okumasında yanlış bir değer vereceği düşünülmez. Bu da iyimserlik üzerine kurulmuştur.
Kaydın, lock’lar ile korunması amacıyla da izolasyan(ISOLATION) terimi kullanılmıştır.
RowVersioning w/Snapshots
ALLOW_SNAPSHOT_ISOLATION ve READ_COMMITTED_SNAPSHOT isolasyon seviyelerinden bahsedildiğinde de concurrency control için sağlanan kayıtların snapshotlarının, Transsactionların neticelenmesine kadar geçen sürede fiziki adreslenmesi gelmelidir. Snapshot kavramı iyi anlaşılırsa, concurrency tekniklerinin nasıl başarıyla uygulandığına da şahit olacaksınız.
Yukarıdaki figürden de anlaşılacağı üzere Snapshot ile oluşturulan Rowversioning tekniği sayesinde kaydın bir önceki ve bir sonraki değerlerine ulaşmak o kadar kolay olacaktır.
Basit anlamda, lock memory’e ait aktif transaction’ın sahipliğinde veritabanının fiziksel olduğu kadar mantıksal(logical) belirli bir objesine erişimi düzenleyen veri objesidir.(data item=datum) İçeriğinde ismi, mode’u, süresi ve hangi transaction’ın kendisini sahiplendiği bilgisi vardır.
Logical (mantıksal) lock’lar, veritabanına ait mantıksal objelerin lock’larıdır. Örneği, bir kolon mantıksal bir objedir ve storage engine katmanında bir page’nin bir kaydıdır. Bu da demek oluyor ki, fiziksel lock ise, fiziksel anlamda buluna bir objeye ait olan lock’lardır. Makalemin girişinde bahsettiğim READ-WRITE ise lock’ın mode’unu belirler. READ için Shared ifadesi kullanılırken, WRITE Mode için ise Exclusive ifadesi kullanılır. LOCKING Meknaizması ise basit anlamda, LOCK ve UNLOCK (EXPANDING vs SHRINKING) safhalarında gerçekleşir. Locking safhalarında ise kontrolü sağlayan adında anlaşılacağı üzere spinlock’lar (LOCK’ın yaşam döngüsünü kontrol eden kod parçacıkları) mevcut iken LOCKING tamamen CPU’ya ait scheduler’ların görevidir.
SQL Server’da bulunan LOCK ve LOCKING Mekanizmalarını READ-WRITE perspektifinden makalemin ikinci serisinde anlatacağım.
Referanslar: