Hepimizin bildiği gibi READ UNCOMMITTED, kirli okumalar ve fantom okumaları gibi şeylerin gerçekleşebileceği en düşük izolasyon düzeyidir. Bu izolasyon seviyesini kullanmak için en uygun zaman ne zamandır ve hangi nedenlerle kullanılabilir?
Aslında cevapları daha önce okudum, ama tam olarak anlayamadım çünkü yeterli örnek yoktu.
Yanıtlar:
SSMS'den üretim veritabanlarını sorgularken READ_UNCOMMITTED(veya NOLOCK) uygulama kodundan rutin olarak kullanmıyorum (veya ). Bu uygulama (MAXDOP 1 sorgu ipucu ile birlikte), veri analizi ve sorun giderme için geçici sorguların üretim iş yükünü etkilememesine yardımcı olur ve sonuçların doğru olmayabileceğini anlar.
Ne yazık ki, veri bütünlüğü pahasına engellemeyi önlemek için üretim kodunda yaygın olarak görüyorum READ_UNCOMMITTED/ NOLOCKkullanıyorum. Uygun çözüm satır sürüm yalıtım düzeyi (olduğu SNAPSHOTveya READ_COMMITTEDbirlikte READ_COMMITTED_SNAPSHOTveritabanı seçeneği ONsorgu ve endeks ayarı için) ve / veya dikkat.
Son zamanlarda kod NOLOCKbazen sadece yanlış sonuçlar verdi çünkü tek değişiklik kaldırmak oldu bir proc gözden geçirdi . Kaldırmak NOLOCKiyi bir şeydi, ancak eksik veya çoğaltılmış satırların genellikle büyük tabloların ayırma sırası taramaları sırasında gerçekleştiğini bilerek, UNION ALLverimli dizin kullanımını teşvik etmek için bir teknik kullanmak için yeniden düzenleme önerdim . Sorgu şimdi tüm dünyaların en iyisi olan doğru sonuçlarla birkaç milisaniyede çalışıyor.
Sonuçları kabul ettiğiniz ve başka seçenekleriniz olmadığı sürece bazı durumlarda iyi olduğunu düşünüyorum .
Diğer seçenekler için, insanları yeni uygulamalar için Taahhüt Edilen Anlık Görüntü İzolasyonunu (RCSI) veya eski uygulamalar için SNAPSHOT ISOLATION (SI) kullanmaya yönelirdim.
Ancak, bunlar uygun olmayabilir. Tempdb'i sevmek ve önemsemek için biraz zaman harcamanız gerekebilir ve hiç kimsenin sürüm deposunun (ve tempdb) büyümesini ve diski doldurmasını sağlayan açık bir işlem bırakmadığından emin olun.
Bir DBA'nız yoksa veya işi SQL Server'ınızı izlemek ve yönetmek olan biri yoksa, bu seçenekler tehlikeli olabilir. Daha genel olarak, herkesin SI'ya sorun sorgularını sormak için bağlantı dizesini veya kodunu değiştirebilecekleri sunucuya giden kod üzerinde tam denetimi yoktur.
Bunun yanı sıra, çoğu insanın tüm uygulamalarında kilitleme problemleri yoktur . OLTP verilerinin raporlanması gibi konularla ilgili sorunları var. Yazarlar tarafından engellenmeyen raporlar karşılığında NOLOCK / RU takaslarını kabul edebiliyorsanız, bunun için gidin.
Bunun ne anlama geldiğini anladığınızdan emin olun. Bu, sorgunuzun herhangi bir kilit almadığı anlamına gelmez , diğer sorguların çıkardığı kilitlere uymadığı anlamına gelir.
Ve elbette, sorununuz yazar / yazar kilitleme ise, yardımcı olacak tek seçenek SI'dır, ancak hata işleme, vb.
IMHO, modern bir sistemde UNCOMMITTED READ için tek geçerli kullanım örneğini geliştirme sırasında bir oturumdan başka bir oturumda hata ayıklamaktır, böylece örneğin bir depolanmış proc çalışırken hala ne yaptığını görebilirsiniz. Asla normalde bir üretim sisteminde kullanılmaz. Bazı küçük performans kazançları olabilir, ancak uzun vadede buna değmez.
Sağlık hizmetlerinde her zaman kullanıyoruz.
Tek tek veri satırlarının sorgunun ortasında değişmesi şaşırtıcı derecede nadirdir ve okuma / yazma oranı 10.000 / 1 gibidir - ve bunların çoğu güncellemeler değil, eklemelerdir. Örneğin, laboratuvar arayüzü hastanın laboratuvar sonuçlarını veritabanına yazdığında, bu değerler asla değişmeyecektir.
Veri zaman yapar değişim, bir seferde bir satır değiştirir. Kimse tüm sütunları güncellemiyor (gerçekten kötüleştiklerinde DBA hariç).
Öte yandan, 72 saat veya daha kısa sürede ER'ye geri gelen hastalar gibi şeyleri taramak için bir sürü sorgu yürütüyoruz, bu da tabloları kesinlikle bozuyor.
Sağlık SQL 10 yıl içinde, hiç görmedim Rollback Transaction. Son kullanıcı deneyimini bozmadan içeri girip çıkmak istiyorum. OLTP veritabanını yavaşlatma riski ve kötü veri alma riski düşükse, NOLOCK olurum.
Kullanmalı mıyız? Belki, belki değil. Genel olarak, üzerinde çalıştığım uygulama veritabanlarının çoğunun iyi tasarlanmış olduğunu söyleyemem. Normalde anti-desenlerle doludur.
READ_UNCOMMITTED/NOLOCKverinin doğruluğu gerçekten ana hedef olmadığında iyi bir seçenektir. Bazen gerekli olan yaklaşık bir toplam sayım olduğunda. Örneğin: Tabloları INSERT ya da UPDATE için kullanılan saklı yordamlar vardır. Bazen güncellenecek veya eklenecek kayıt sayısı çok fazladır (Binlerce kayıt). Bu saklı yordam çalışmaları sırasında, NOLOCKdüzgün ilerleyip ilerlemediğini görmek için hedef tabloda basit bir seçme sorgusu periyodik olarak çalıştırabiliriz (Güncelleme sorgusu için, güncellenen kayıtlar için bir durum değişikliği sütununuz varsa, group bysorguyu çalıştırmak için bu sütunu kullanabiliriz. NOLOCKDurum değişikliği sayısının sürekli değişip değişmediğini bulmak için).
READ UNCOMMITTED'in sadece kirli okumalar değil ek tutarlılık sorunları getirdiğini unutmayın. Erişim yöntemine bağlı olarak, satırları kaçırabilir, hatta aynı satırı birden çok kez okuyabilirsiniz. Detaylar ile ilgileniyorsanız, Itzik Ben-Gan'ın makalesini okuyun