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ı bir şeyler karalamıştım. Belki faydası olabilir.

Buradaki cevaplar 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ı: 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
  Toplu insert işlemi hız sorunu (Çözüldü) adelphiforumz 9 3.126 13-12-2021, Saat: 20:23
Son Yorum: apachi2006
  SQL 2019 bekleme sorunu m_ekici 13 7.220 28-10-2020, Saat: 12:28
Son Yorum: m_ekici
  MSSQL Sorgulama Sorunu bkantur 11 6.173 14-09-2020, Saat: 13:50
Son Yorum: sabanakman
  Database ve tablo isimlerini parametre olarak kullanma denizfatihi 5 3.995 02-01-2020, Saat: 18:07
Son Yorum: yasard
  MSSQL StoreProcedure Performans Sorunu (Çözüldü) adelphiforumz 23 14.425 18-09-2019, Saat: 14:13
Son Yorum: Bay_Y



Konuyu Okuyanlar: 1 Ziyaretçi