Deyimi Silme ile ilgili Kilitlenme

Bir SQL Server İş çalıştığında bir kilitlenme olsun. Kilitlenme, basit bir DELETE deyiminde oluşur. Ben deadlock neden çalışan bir SELECT / UPDATE sorgu olması gerektiğini düşünürdüm? Ama görünüşe göre DELETE / DELETE kilitlenme ...

Aradığım şey neden bir DELETE / DELETE kilitlenme alıyorum. (Benim bildiğim kadarıyla) farklı parametrelerden geçiyor.

Herhangi bir fikir? Teşekkürler.

deadlock-list
2014-05-20 07:30:09.66 spid25s      deadlock victim=process409048
2014-05-20 07:30:09.66 spid25s       process-list
2014-05-20 07:30:09.66 spid25s        process id=process409048 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127294 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x397219620 lockMode=U schedulerid=5 kpid=3792 status=suspended spid=150 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process432e08 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=2648 ownerId=629859744 transactionname=DELETE lasttranstarted=2014-05-20T07:30:04.833 XDES=0x4c3426b50 lockMode=U schedulerid=6 kpid=5988 status=suspended spid=146 sbid=0 ecid=3 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:04.833 lastbatchcompleted=2014-05-20T07:30:04.820 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629859744 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2
2014-05-20 07:30:09.66 spid25s     DELETE FROM dbo.UserDetailsData WHERE        (Username = @P1) AND (UserDate = @P2)     
2014-05-20 07:30:09.66 spid25s          frame procname=unknown line=1 sqlhandle=0x000000000000000000000000000000000000000000000000
2014-05-20 07:30:09.66 spid25s     unknown     
2014-05-20 07:30:09.66 spid25s         inputbuf
2014-05-20 07:30:09.66 spid25s        process id=process39ea562c8 taskpriority=0 logused=0 waitresource=PAGE: 12:1:7127916 waittime=4352 ownerId=629860973 transactionname=DELETE lasttranstarted=2014-05-20T07:30:05.307 XDES=0x13e0e4b50 lockMode=U schedulerid=2 kpid=7124 status=suspended spid=150 sbid=0 ecid=1 priority=0 trancount=0 lastbatchstarted=2014-05-20T07:30:05.307 lastbatchcompleted=2014-05-20T07:30:05.307 clientapp=QSQL25 hostname=MORRIS hostpid=1528 isolationlevel=read committed (2) xactid=629860973 currentdb=12 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
2014-05-20 07:30:09.66 spid25s         executionStack
2014-05-20 07:30:09.66 spid25s          frame procname=adhoc line=1 stmtstart=68 sqlhandle=0x020000000b887a18f75d0aa07c25a9b8630fca696aa0e5d2

sql-server deadlock

— K09
kaynak

Hayır, SELECT / UPDATE dışındaki diğer senaryolarda kilitlenme oluşabilir. Gerçekten ihtiyacınız olan her biri diğerinin elinde tuttuğu bir kaynağa ihtiyaç duyan iki işlemdir. (1) DELETE ifadeleri daha büyük bir işlemin parçası mı? (2) Kilitlenme XML'sini crappy hata günlüğü metni yerine bir yere gönderebilir misiniz?

— Aaron Bertrand

Lütfen dbo.UserDetailsDatatüm dizinleri içeren tablo şemasını gönderebilir misiniz ? Ayrıca, bu ifadelerin aynı parametrelerle çağrılıp çağrılmadığını biliyor musunuz? Her ikisinin de sıfır günlüğü kullanıldığından dolayı, tüm yapmanız gereken aramaları seri hale getirip getirmediğini merak ediyorum, çünkü birbirlerine adım atıyorlar.

— Jon Seigel

XML'i nasıl edinebilirim? SQL Server hata günlüklerinden hatayı aldım. İfadeler farklı parametrelerle çağrılır. Kısa süre önce UserDate alanına filtre uygulayan bir dizi filtrelenmiş dizin ekledik.

— K09

Profiler'daki kilitlenme grafiği olayını yakalayın. Ardından, yakaladıktan sonra satırı sağ tıklayın -> olay verilerini ayıklayın -> bir yere .xdl olarak kaydedin ve içeriğini (xml'dir) Pastebin'e (veya benzer bir yere) gönderin.

— Marian

Merhaba, XML burada yayınladı ... Umarım bu yardımcı olur! dl.dropboxusercontent.com/u/16953128/DeadlockTest.xdl

— K09

Aradığım şey neden bir DELETE / DELETE kilitlenme alıyorum.

Görünüşe göre kilitlenme meydana gelir:

spid 54 ecid 0üzerinde bir update ( U) sayfası kilidi alırPAGE: 12:1:5147422
spid 166 ecid 3Uaynı sayfada güncelleme ( ) sayfası kilidi istiyor ve engelleniyor
spid 54 ecid 2Uaynı sayfada güncelleme ( ) sayfa kilidi istiyor ...

Sayfalar sorgu için önceden getiriliyor ve güncelleme kilitleri alındı ecid 0. Bu yukarıdaki 1. adımdır. 3. adımda, aynı paralel sorgunun ( ecid 2) bir alt iş parçacığı aynı kilidi ister. Normalde bu bir sorun olmazdı. SQL Server , aynı üst sürecin iş parçacıklarını bilir ecid 0ve ecid 2iş parçacıklarıdır. Ne yazık ki, 2. adım buna engel olur ve bir kilitlenme ortaya çıkar.

Bununla birlikte , kilitlenmenin neden oluştuğunu gerçekten önemsememelisiniz , önemli soru, bundan nasıl kaçınacağınızdır. Cevap, için etkili bir erişim yolu sağlamaktır DELETE. İfadenin satırları bulması WHERE Username = @P1 AND UserDate = @P2gerekir, bu nedenle bu sütunlara bir dizin girmelisiniz.

Ve tabii ki böyle bir endeksiniz var. Asıl soru sorunlarınız filtrelenen endeksleri eklendi sonrasında ortaya çıkıyor nedeni budur.

Bunun cevabı, silinecek (ve tahminlerini kontrol edecek) filtrelenmiş dizin satırlarını bulmak için ekstra sütun bilgisidir. Sorgu dar / satır başına yürütme planı kullanıyorsa , yürütme altyapısı geniş / dizin başına planda olduğu gibi Kümelenmiş Dizin Silme işlecindeki fazladan sütunları alamaz.

Bununla ilgili daha fazla ayrıntı ve bu blog gönderisinde çalışan bir örnek bulabilirsiniz .

Bu durumda, sütun bilgisinin planın Kümelenmiş Dizin Silme'nin sağındaki kısmından gelmesi gerekir ve bu nedenle paralel kümelenmiş bir dizin taraması kullanılır ve yüksek kilitlenme potansiyeli olan yavaş bir sorgu alırsınız.

Cevap aşağıdakilerden birini yapmaktır:

Filtrelenmiş dizinleri kaldırın
Mevcut ad / tarih dizinine filtrelenmiş dizin anahtarı / ekle / yüklem sütunları ekle
Geniş bir güncelleme planını zorla ( bunu yapmanın desteklenen bir yolu yok)
Anlık görüntü yalıtımı altında sorguyu çalıştırın (RCSI değil)

Seçenek 2 benim güçlü tercihim olacaktır.

Seçenek 4 (teşekkürler Jack Douglas), kilitlenmeleri kaldırma avantajına sahiptir ve değişikliklerin ayrık doğası göz önüne alındığında, herhangi bir "güncelleme çakışmasına" neden olmamalıdır , ancak veritabanı düzeyinde anlık yalıtımın etkinleştirilmesini, yalıtım düzeyinin açıkça değiştirilmesini gerektirmektedir, ve altta yatan sorunu çözmeyecek : yine de güzel bir dizin aramasının gerçekten istediğiniz şey olduğu savurgan bir paralel tablo taraması ile sonuçlanacaksınız.

— Paul White 9
kaynak