Sql Server kullanan ve gerçek zamanlı çalışan uygulamalarda lock lar çok sık yaşanmaktadır. Uygulama geliştirici olarak düşündüğümüzde lock ların oluşması kötü bir durumdur ve sağlıklı çalışan sistemlerde en aza indirmek gerekmektedir. Peki lock neden oluşur? Database engine veri tutarlılığını sağlamak amacıyla bir kaynağa sadece bir thread in erişmesine izin verir. Lock kullanılmadığı durumda aynı veri farklı prosesler tarafından çeşitli işlemlere maruz kalacaktır. Özetle veri tutarlılığını sağlamak adına lock lar aslında faydalı bir durumdur.
Veritabanı yöneticisi için lock ların yönetilmesi bir zorunluluktur. Çok sayıda lock oluşan sistemlerde çözüm olarak; lockların hangi sayıda oluştuğu, hangi proseslerde daha fazla oluştuğu ve hangi frekansta lock ların oluştuğu izlenmelidir.
Sistemde transaction sayısı fazlaysa veya aynı kaynağa ulaşan uygulama sayısı fazlaysa lock lar oluşacaktır.Lock oluştuğu tespit edilen kaynak üzerinde işlem yapan prosesleri sınırlandırmak bir çözüm olabilir.
İzleme aşamasında sql server 2000 de bulunan sp_lock prosedürü lock ları listelememizi sağlar. Bu prosedür master database deki lock bilgilerinden lock detaylarını bize verir. Her lock için "granted","converting","waiting lock" gibi lock durumlarını görebiliriz.
EXECUTE sp_lock cümlesini çalıştırdığımızda;
spid, dbid, objid, indid, type, resource, mode, ve status kolonlarını görebiliriz. Bu veri aslında bize tam olarak açıklayıcı bir bilgi vermeyecektir.
spid sql server a yapılan bağlantının kimlik numarasıdır.
execute sp_who kullanarak o spid nin hangi user tarafından oluştuğunu görebiliriz.
dbid lock ın oluştuğu database id sini verir.
SELECT * FROM sysdatabases cümlesini kullanarak o database id nin hangi database i gösterdiğini bulabiliriz.
objid database de hangi nesnede lock oluştuğunu gösterir.
Master database inde SELECT * FROM sysobjects cümlesiyle tüm nesne detaylarını görebiliriz.
Bir kaç lock oluştuğunda izlenmesi kolay olabilir ama 1000 civarında lock oluşan bir uygulamada izlemek pek de kolay olmayacaktır. Ayrıca lock ları her listelememizde farklı bir kayıt seti alacağız. Bunun nedeni her an yeni lock ların oluşması ve eski lock ların serbest kalmasıdır.
Eğer aynı id ye sahip çok sayıda lock varsa bu proses büyük transactionlar içerir ve diğer transaction ları da etkiler. Bu durumda
DBCC INPUTBUFFER(spid) cümlesini çalıştırarak EventInfo bilgisini görebiliriz.
Yavaş çalışan sistemlerde çok fazla lock oluşacağını söyleyebiliriz. Lock lar genellikle bir kaynağı uzun süre kullanan yani esir alan uzun sorgulardan veya aynı kaynağı kullanmak zorunda olan iki kritik proses (deadlock) sebebiyle oluşur. Çözüm olarak genelde tercih edilen kill process işlemi bilhassa çok fazla lock oluşan sistemlerde iyi bir çözüm değildir. Tek çözüm lock ları analiz edecek bir sistem geliştirmektir. Bu analiz sonucunda uygulamada çeşitli değişiklikler yapıp lock ları en aza indirmek gerekecektir.
0 yorum:
Yorum Gönder