Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5
read committed snapshot Tablo kilitleme Sorunu
#1
Veri Tabanının isolation level'i
read committed snapshot normal şartlarda bir transaction başladığında tabloda ve kayıtta herhangibi kilitleme olmuyor ve bu şekilde 10 larca farklı clienttan aynı tabloya yoğun veri yazıyorum

Transaction başladıkdan sonra bir kayıtta update,delete işlemi yapılırsa;
Başka bir connection'da aynı kayda select yaparsa sıkıntı yok 
update veya delete yapmaya çalışırsa transactionı bekliyor. 

Yani kayıt update ve delete de başka bir connectionnın update veya delete yapmasına izin vermiyor.

Buraya kadar sıkıntı yok problemim şurda başlıyor
1.Connection Transaction'ı başlattıp tabloda bir kayıt sildiğinde
2.Connection FARKLI bir kayıt delete işlemi yapamıyor

1.Connection
BEGIN TRANSACTION;  
delete from STOK_HAR WHERE COUNTER=2207002
--ROLLBACK; 


2.Connection
 delete from STOK_HAR WHERE COUNTER=1632 --Bu sorgu çalışmıyor bekliyor

*Kayıt Sayısı az tablolarda aynı işlemde sıkıntı olmuyor sadece kaydı kilitliyor, fakat fazla olanlarda tüm tabloyu kilitliyor
*select lock_escalation_desc from sys.tables where name='STOK_HAR' Kilit Yükseltme modu TABLE olarak gözüküyor ama az kayıtlı olanlarda da TABLE olmasına
rağmen sadece kaydı kilitliyor

Bu Sorun aşmanın bir yolu var mıdır?
Teşekkür ederim.
Cevapla
#2
Kardeş sitemiz üzerinde bir zamanlar konu ile alakalı Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.. Belki faydası olabilir.

Buradaki Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız. da işe yarayabilir.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#3
Hocam önceki yazılarınızı okudum
read committed snapshot
sizinde önerdiğiniz gibi bizim için "hayat kurtarıcı"  ama
sanrım burada tabloda ki kayıt yoğunluğundan dolayı yine sizin belirttiğiniz gibi
("Ancak kilitlenecek satırların çok fazla olması durumunda Sql Server Lock escalation adı verilen bir kilit yükseltme senaryosunu devreye alır ve satır bazlı kilitten Page bazlı kilitlemeye hatta o da yeterli gelmez ise tablo bazlı kilitlemeye yükseltebilir.")
tablo bazında kilitlemeye geçiyor.
ve
bunun içinde alabileceğim tek önlem trasaction sürelerini kısaltmak gibi gözüküyor.
doğrumu anlamışım
Cevapla
#4
(12-10-2018, Saat: 16:39)emrahgs Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Üye Olmanız Gerekiyor. Üye Olabilmek İçin Lütfen Buraya Tıklayınız.Hocam önceki yazılarınızı okudum
read committed snapshot
sizinde önerdiğiniz gibi bizim için "hayat kurtarıcı"  ama
sanrım burada tabloda ki kayıt yoğunluğundan dolayı yine sizin belirttiğiniz gibi
("Ancak kilitlenecek satırların çok fazla olması durumunda Sql Server Lock escalation adı verilen bir kilit yükseltme senaryosunu devreye alır ve satır bazlı kilitten Page bazlı kilitlemeye hatta o da yeterli gelmez ise tablo bazlı kilitlemeye yükseltebilir.")
tablo bazında kilitlemeye geçiyor.
ve
bunun içinde alabileceğim tek önlem trasaction sürelerini kısaltmak gibi gözüküyor.
doğrumu anlamışım

Kesinlikle doğru. Transaction'lar mümkün olan en kısa sürede başlayıp bitmelidir. Aksi taktirde bu tarz kilitlenmeler yoğun bir şekilde yaşanır. Aslında derinliklerde, critical section, event, mutex, semaphore vb. senkronizasyon mekanizmaları kullanıldığı için bu tarz sonuçların oluşması sürpriz değil.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla


Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Tablo İsimlendirme mustafasivlin 11 969 08-04-2019, Saat: 09:29
Son Yorum: edo
  .duvomywy uzantılı dosya sorunu glagher 13 1.163 13-12-2018, Saat: 11:15
Son Yorum: forumcuali
  MSSQL Insert Türkçe Karakter Sorunu hi_selamlar 17 1.736 02-09-2018, Saat: 22:28
Son Yorum: hi_selamlar
  Tablo Birleştirmek Mericx 7 1.642 26-01-2017, Saat: 13:57
Son Yorum: Mericx



Konuyu Okuyanlar: 1 Ziyaretçi