Satır Düzeyi ile Sayfa Düzeyi Kilitleme ve Sonuçları Arasındaki Fark


10

Bakım Planımı çalıştırmaya çalışırken aşağıdaki hatayı alıyorum:

"" Sorgusunu yürütmek aşağıdaki hatayla başarısız oldu: "" tablosundaki "" dizini "(bölüm 1), sayfa düzeyi kilitleme devre dışı bırakıldığı için yeniden düzenlenemiyor."

Şu anda bu Dizin'de Satır Düzeyi kilitleme etkin. Sayfa Düzeyi kilitlemeyi etkinleştirebilirim, ancak yansımaların ne olduğundan emin değilim.

Benim sorum: İki kilitleme şeması arasındaki fark nedir ve gerçek dünyalarının (üretimde) sonuçları nelerdir?

Yanıtlar:


14

"" Sorgusunu yürütmek şu hatayla başarısız oldu: "" tablosundaki "" dizini "(bölüm 1), sayfa düzeyi kilitleme devre dışı bırakıldığı için yeniden düzenlenemiyor."

Bakım planı, çevrimiçi bir işlem olan bir ALTER INDEX REORGANIZE girişiminde bulunmalıdır. Parçalanmayı gidermek için (sıralı olmayan sayfalar) sayfalar kilitlenmeli ve taşınmalıdır; sayfa kilitleri devre dışı bırakılmışsa bu mümkün değildir. Sayfa kilitleri olmadan birleştirme yapmanın tek yolu, REORGANIZE için yalnızca çevrimiçi olduğu için mümkün olmayan tüm bölümü kilitlemektir.

İki kilitleme şeması arasındaki fark nedir ve gerçek dünyalarının (üretimde) sonuçları nelerdir?

Belirli bir kilit türüne izin vermemenin etkisini değerlendirmek için bir kaydın ve sayfanın ne olduğunu kavramanız gerekir. SQL Server depolama iç elemanlar bilmiyorsanız, başlamak bir Record Anatomy ve bir Sayfa Anatomy . Çok basit bir ifadeyle:

  • satırlar = kayıtlar
  • satırlar 8 kb'lik sayfalarda saklanır

İzin verilen kilit türlerini değiştirirseniz:

  • Sayfa kilitlerini devre dışı bırak = Yalnızca satır ve tablo kilitleri
  • Satır kilitlerini devre dışı bırak = Yalnızca sayfa ve tablo kilitleri
  • Her ikisini de devre dışı bırak = Yalnızca tablo kilitleri

Bir kilit türüne izin vermemenin nerede yararlı olabileceğinin farkında olduğum iki senaryo var. Başkaları olmadığı anlamına gelmez, umarım başka biri örneklerle devreye girer.

Sıklıkla değişen sık erişilen bir arama tablosu - Sayfa ve satır düzeyi kilitlerini devre dışı bırakarak, tüm okuyucular paylaşılan bir tablo kilidi alacaktır. Bu, tabloda genel olarak paylaşılan niyetten daha hızlı / daha ucuzdur, ardından bir sayfada niyet paylaşılır ve son olarak belirli bir satır veya satırlarda paylaşılan bir kilit gelir.

Belirli bir kilitlenme senaryosunu önleme - Aynı sayfada sık sık kilit elde eden eşzamanlı işlemlerin neden olduğu kilitlenmelerle karşılaşırsanız, satır kilitlerine izin verilmemesi sayfa kilitlerinin alınmasına neden olur. Bu durumda sayfaya yalnızca bir işlem erişebilir, diğeri beklemelidir.

İlk örnek mikro optimizasyon ve tipik bir sistemde ölçülebilir fayda sağlama olasılığı düşüktür. İkincisi, bu özel kilitlenme senaryosunu çözecektir, ancak beklenmeyen yan etkiler ortaya çıkarabilir, örneğin kodun farklı bir bölümünde eşzamanlılığı öldürmek. Etkiyi tam olarak değerlendirmek zor, dikkatle yaklaşın!

Varsayılan değer her ikisinin de etkinleştirilmesidir ve bu iyi bir sebep olmadan değiştirilmemelidir .


9

Muhtemelen hiçbirşey. Eminim MS sizden daha iyi bilir

Yüksek hacimli OLTP sistemleri üzerinde çalıştım ve ayarları değiştirmeye hiç ihtiyaç duymadım. Bir çıkmaz yeniden denenmeli çünkü zaten olacaklar

SQL Server Storage Engine blogundan alıntı yaparak , "SQL2005'te Kilit İletmeyi Kilitle" n.

Varsayılan olarak, hem ROW hem de PAGE kilitleri etkin durumdadır ... SQL Server çoğu durumda ROW kilidi ayrıntı düzeyini seçer, ancak uygun olduğunda PAGE kilidini seçebilir. Bu nedenle belirttiğiniz durumda ROW kilidi büyük olasılıkla. Veritabanı veya örnek düzeyinde PAGE kilidini kapatmanın bir yolu yoktur. PAGE kilitleri nedeniyle engelleme ile mi karşılaşıyorsunuz?

Sadece rowlock'ları zorlarsanız, başka yerlerde daha etkili kullanılabilecek kaynakları tüketeceğinizi düşünürüm. Yükünüz önemli olacak kadar yüksekse, neden bellek tüketmelisiniz? Blog makalesi buna giriyor

Bunun gibi bir batıl inanç var, sanki bunlar gibi:


+1 ancak: OLTP sistemlerinde kilitlenmeler önlenebilir; haftada 2-3 kez konuşlandırmamıza rağmen sistemim aylarca kilitlenmeden çalışıyor.
AK
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.