“Veri hareketi nedeniyle NOLOCK ile taramaya devam edilemedi” nasıl çoğaltılır


10

Belirli sorgularda NOLOCKbulunan bazı büyük işler için bazen "Veri hareketi nedeniyle taramaya devam edilemedi" mesajı alıyorum WITH (NOLOCK).

Bunun, verilerin artık olması gerektiği yerde olmamasına neden olan bir sayfa bölünmesi olduğunda veri seçmeye çalışmakla ilgili bir şey olduğunu anlıyorum - ortamımda olan şeyin bu olduğunu varsayıyorum.

Bunu nasıl çoğaltırım?

Hatayı yakalamak ve bu olduğunda yeniden denemek için kısa vadeli bir geçici çözüm yapmaya çalışıyorum, ancak yeniden üretemiyorsanız test edemiyorum. Buna neden olmanın makul bir yolu var mı?

Bu olduğunda, sorguyu yeniden yürütmek başarı ile sonuçlanır - bu yüzden gerçek veri veya veritabanının kalıcı olarak bozulmasından endişe etmiyorum. Sorgudaki bazı tablolar (dizinleriyle birlikte) sık sık düşüyor, yeniden oluşturuluyor ve yeniden dolduruluyor, bu yüzden bununla ilgili bir şey olduğunu varsayıyorum.

Kaldırmak NOLOCKbenim uzun vadeli sorunum. Bunun ilk nedeni NOLOCK, sorgular o kadar kötü ki, günlük işlemlerle tıkanmış olmalarıydı, bu yüzden NOLOCK(işe yarayan) kilitlenmeleri durdurmak için bir yara bandı oldu. Bu yüzden kalıcı bir çözüm bulana kadar bir yara bandında yara yardımına ihtiyacım var.

Bir Merhaba Dünya ile yeniden üretebilseydim, grup yardımını muhtemelen bir saatten kısa bir sürede işe atmayı planlıyordum. Arama ve değiştirme kaldırılamıyor NOLOCK, çünkü uygulama kilitlenmelerini tekrar almaya başladım, bu da benim için ara sıra başarısız olan bir işten daha kötü.

Okunmuş anlık görüntü yalıtımı kullanmak iyi bir olasılıktır - bunun hakkında daha fazla bilgi almak için veritabanı ekibimizle çalışmam gerekecek. Sorunumuzun bir kısmı, bu tür bir şeyle başa çıkmak için bir SQL Server uzmanına sahip olmamamız ve yalıtım düzeylerini şu anda bu değişikliği yapacak kadar iyi anlamıyorum.


1
NOLOCKBu işlerden basitçe çıkarmayı düşündünüz mü ? Bu sorguların sonuçlarının doğru olması gerekiyorsa , endişeleriniz en az 601 olmalıdır . Paul White, burada mümkün olmaması gereken verileri okumak için özellikle korkunç bir örnek gösteriyor .
Aaron Bertrand

3
Sen ayarlayabilirsiniz DEADLOCK_PRIORITYiçin LOWuygulamalar kilitlenmeleri varsa, işler başarısız olur, böylece işlerinde değil,. Bundan sonra, kilitlenmeleri araştırabilir ve neden olduklarını öğrenebilir ve bu sorunu çözebilirsiniz. İki ifadenin sırasını değiştirmek gibi çok basit bir düzeltme olabilir. Ne olursa olsun bir sorun, NOLOCKbir çözüm olmadığını durdurma o kolay sırf olmaya zorlamak için çalışıyor, bu yüzden.
Aaron Bertrand

@AaronBertrand Teşekkürler, DEADLOCK_PRIORITY hakkında bilmiyordum - Buna bakacağım. Kilitlenmeleri izlemeyi denedik, ancak bunlar rastgele görünen çeşitli zamanlarda ve günde sadece bir veya iki kez gerçekleşti ve talep üzerine hiçbir zaman tekrarlanamıyor - planlanan işlerimiz her saat on binlerce sorgu çalıştırıyor ve uygulamamız yüzlerce yürütüyor bir sayfayı yüklediğinde veya bir şey kaydettiğinde sorguların her iki tarafındaki hangi sorgunun kilitlenmeyle ilgili olduğunu izlemedik. NOLOCK'u sonsuza kadar orada bırakmak gibi bir amacım yoktu, bu yüzden daha iyi uzun vadeli çözümler araştırıyoruz.
wookie23

1
Kilitlenmeleri izlemekte zorlandığınızı söylemiştiniz. 2008 R2'de olduğunuz göz önüne alındığında, buraya bakabilirsiniz: sqlservercentral.com/articles/deadlock/65658 Jonathan Kehayias, halka arabelleğinden kilitlenme bilgilerini çekmeye devam ediyor.
Kenneth Fisher

Cevaplar ve yorumlar altta yatan problemi iyi ele alıyor, ancak yine de bunu entelektüel bir egzersiz olarak yeniden üretmenin bir yolunu bulmak istiyor musunuz?
James L

Yanıtlar:


8

NOLOCK sorunlarına yönelik olası bir 'grup yardımı' NOLOCK'u kullanmayı bırakmak ve READ_COMMITTED_SNAPSHOT izolasyonunu kullanmaya başlamak olduğundan, sizi http://www.brentozar.com adresinden Kendra Little: Snapshot veya Read Comided'ın uyguladığı blog yayınına yönlendirmek istiyorum SQL Server'da Anlık Görüntü Yalıtımı: Bir Kılavuz .

Kendra, READ_COMMITTED_SNAPSHOT yalıtım seviyesini kullanarak faydalar ve riskler hakkında adil bir ayrıntı sunar.

  1. Bu yalıtım düzeyi, veritabanı kodu için varsayılan yalıtım düzeyi olur.
  2. READ_COMMITTED_SNAPSHOT yalıtım düzeyinde değişiklik yapabilmek için veritabanında yalnızca bir kullanıcının olması gerekir.
  3. READ_COMMITTED_SNAPSHOT yalıtımı kullansanız bile , varsayılanı geçersiz kıldıkları için NOLOCK ipuçlarını kaldırmanız gerekir .
  4. Kodunuzun bazılarında iyileştirilmesi gereken sorunlar olabilir.

Birkaç yıl önce , engellemekten ciddi şekilde muzdarip bir veritabanına READ_COMMITTED_SNAPSHOT yalıtımı uyguladık . Ancak izolasyon düzeyini değiştirdiğimizde, birkaç kritik alanda çıkmaza girmeye başladık .

Bu neden oldu? Önceki yalıtım seviyesi ağır engellemeye neden olduğundan, kod kilitlenme noktasına "asla" ulaşamazdı. Ancak, READ_COMMITTED_SNAPSHOT yalıtımı ile sorgular ilerlemeye devam edebilir. Ancak, artık beklemeyen işlemlerin bir kısmı kilitlenmeye başladı.

Neyse ki durumumuz, kilitlenme noktalarını belirleyerek ve birkaç tablodaki dizinleri daha rasyonel bir sütun sırasına göre ayarlayarak hızlı bir şekilde çözüldü. Bu, kilitleme sorunlarımızı büyük ölçüde azalttı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.