NEDEN YETKİSİZ BİR OKUMA izolasyon seviyesi kullanılmalı?

Düz İngilizce'de kullanmanın dezavantajları ve avantajları nelerdir?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

uygulamaları ve raporlama hizmetleri uygulamaları için bir sorgulama nasıl yapılır?

Bu izolasyon seviyesi kirli okumalara izin verir. Bir işlem, başka bir işlem tarafından yapılan taahhüt edilmemiş değişiklikleri görebilir.

En yüksek izolasyon düzeyini korumak için, DBMS genellikle veri kilitleri elde eder, bu da eşzamanlılık kaybına ve yüksek kilitleme yüküne neden olabilir. Bu izolasyon seviyesi bu özelliği rahatlatır.

Birkaç örnek ve daha fazla okuma için Wikipedia makalesineREAD UNCOMMITTED göz atmak isteyebilirsiniz .

Ayrıca Jeff Atwood'un kendisi ve ekibinin Stack Overflow'un ilk günlerinde bir kilitlenme sorunuyla nasıl başa çıktığıyla ilgili blog makalesine göz atmak da ilginizi çekebilir . Jeff'e göre:

Ama nolocktehlikeli mi? read uncommittedİle geçersiz verileri okuyabilir misiniz ? Evet, teoride. Size ve hepsine ASİT bilimini düşürmeye başlayan veritabanı mimarisi astronotlarında herhangi bir sıkıntı görmeyeceksiniz, ancak denemek istediğinizi söylediğinizde bina yangın alarmını çekeceksiniz nolock. Bu doğru: teori korkutucu. Ama bence şu: "Teoride teori ve pratik arasında hiçbir fark yok. Pratikte var."

Asla nolock herhangi bir veritabanı kilitlenme sorunları için yılan yağı düzeltme genel "ne ails için iyi" olarak kullanmanızı tavsiye ederim . Önce sorunun kaynağını teşhis etmeye çalışmalısınız.

Ancak pratikte nolockkesinlikle bildiğiniz sorguları eklemek basit, anlaşılır salt okunur işler asla sorunlara yol açmaz ... Ne yaptığınızı bildiğiniz sürece.

READ UNCOMMITTEDGöz önünde bulundurmak isteyebileceğiniz seviyeye bir alternatif de READ COMMITTED SNAPSHOT. Jeff'ten tekrar alıntı yapılıyor:

Anlık görüntüler tamamen yeni bir veri değişikliği izleme yöntemine dayanır ... sadece küçük bir mantıksal değişiklikten daha fazlası, sunucunun verileri fiziksel olarak farklı şekilde işlemesini gerektirir. Bu yeni veri değişikliği izleme yöntemi etkinleştirildiğinde, her veri değişikliğinin bir kopyasını veya anlık görüntüsünü oluşturur. Çekişme sırasında canlı veriler yerine bu anlık görüntüleri okuyarak, Paylaşılan Kilitler artık okumalarda gerekli değildir ve genel veritabanı performansı artabilir.

Bu, uzun kesici uç sorgularının ilerlemesini görmek, kaba tahminler (benzer COUNT(*)veya kaba SUM(*)) yapmak vb. İçin yararlı olabilir.

Diğer bir deyişle, kirli okuma sorgularının döndürdüğü sonuçlar, tahmin olarak değerlendirdiğiniz ve bunlara dayalı herhangi bir kritik karar vermediğiniz sürece iyidir.

En sevdiğim kullanım durumu read uncommited, bir işlemin içinde olan bir şeyi ayıklamak.

Kod satırlarında adım adım ilerlerken yazılımınızı bir hata ayıklayıcı altında başlatın, bir işlem açar ve veritabanınızı değiştirir. Kod durduğunda, bir sorgu analizörü açabilir, okunmamış yalıtım düzeyini ayarlayabilir ve neler olup bittiğini görmek için sorgulamalar yapabilirsiniz.

Ayrıca, uzun süren yordamların takılıp takılmadığını veya veritabanınızı doğru şekilde güncelleştirip güncellemediğini görmek için de kullanabilirsiniz.

Şirketinizin aşırı karmaşık saklı prosedürleri yapmayı sevmesi harika.

Avantajı, bazı durumlarda daha hızlı olabilmesidir. Dezavantajı, sonuç yanlış olabilir (henüz işlenmemiş veriler iade edilebilir) ve sonucun tekrarlanabilir olduğuna dair bir garanti yoktur.

Doğruluğu önemsiyorsanız, bunu kullanmayın.

MSDN hakkında daha fazla bilgi :

Kirli okuma veya izolasyon seviyesi 0 kilitleme uygular, bu da paylaşılan kilitlerin verilmediği ve özel kilitlerin onurlandırılmadığı anlamına gelir. Bu seçenek ayarlandığında, taahhüt edilmemiş veya kirli verileri okumak mümkündür; verilerdeki değerler değiştirilebilir ve işlem bitmeden önce veri kümesinde satırlar görünebilir veya kaybolabilir. Bu seçenek, bir işlemdeki tüm SELECT ifadelerindeki tüm tablolarda NOLOCK ayarının yapılmasıyla aynı etkiye sahiptir. Bu, dört izolasyon seviyesinin en az kısıtlayıcı olanıdır.

Ne zaman kullanılabilir READ UNCOMMITTED?

Temel kural

İyi : Sürekli değişen toplamları gösteren büyük toplu raporlar.

Riskli : Neredeyse her şey.

İyi haber şu ki, salt okunur raporların çoğu bu İyi kategorisine giriyor .

Daha fazla detay...

Kullanmak için Tamam:

• Mevcut, statik olmayan veriler için neredeyse tüm kullanıcılara yönelik toplu raporlar, örn. Yılbaşından bugüne satışlar. Giriş hatası veya sadece verilerin dakikadan dakikaya tam olarak ne zaman kaydedildiği gibi rastgele belirsizlik gibi diğer belirsizlik faktörlerinden çok daha düşük bir hata payı (belki <% 0,1) riski altındadır.

Bu muhtemelen bir İş Zekası departmanının SSRS'de yapacağı işlerin çoğunu kapsar. Tabii istisna, önünde $ işaretleri olan bir şeydir. Birçok kişi, müşteriye hizmet vermek ve bu parayı üretmek için gerekli temel metriklere uygulanandan çok daha fazla gayretle para kazanır. (Muhasebecileri suçluyorum).

Riskli olduğunda

• Ayrıntı düzeyine inen raporlar. Bu ayrıntı gerekirse, genellikle her satırın bir kararla ilgili olacağını ima eder. Aslında, engellemeden küçük bir altkümeyi çekemiyorsanız, şu anda düzenlenmiş olmasının iyi bir nedeni olabilir.

• Tarihsel veri. Nadiren pratik bir fark yaratır, ancak kullanıcılar sürekli değişen verilerin mükemmel olamayacağını anlasa da, statik verilerle aynı şeyi hissetmezler. Kirli okumalar burada incinmez, ancak çift okumalar bazen olabilir. Zaten statik veri üzerinde blok olmamalı olarak görmek, neden risk alsın?

• Yazma yeteneğine sahip bir uygulamayı besleyen neredeyse her şey.

Tamam senaryosu bile uygun olmadığında.

• Büyük tekli işlemleri kullanan herhangi bir uygulama veya güncelleme işlemi var mı? Rapor ettiğiniz birçok kaydı kaldıran ve tekrar ekleyen olanlar? Bu durumda NOLOCK, bu tablolarda hiçbir şey için gerçekten kullanamazsınız .

Raporlama ile ilgili olarak, bir sorgunun veritabanlarını kapatmasını önlemek için tüm raporlama sorgularımızda kullanırız. Bunu yapabiliriz çünkü mikrosaniye veriyi değil tarihsel verileri çekiyoruz.

Kaynağın değişme olasılığının düşük olduğu durumlarda READ_UNCOMMITTED kullanın.

• Geçmiş verileri okurken. örneğin, iki gün önce gerçekleşen bazı dağıtım günlükleri.
• Meta verileri tekrar okurken. örn. meta veri tabanlı uygulama.

Getirme işlemi sırasında sosun değişebileceğini bildiğinizde READ_UNCOMMITTED kullanmayın.

Bu size kirli okumalar verir ve henüz yapılmayan işlemleri gösterir. En açık cevap bu. Bunu sadece okumalarınızı hızlandırmak için kullanmak iyi bir fikir değil. İyi bir veritabanı tasarımı kullanıyorsanız bunu yapmanın başka yolları vardır.

Neler olmadığını not etmek de ilginç. READ UNCOMMITTED yalnızca diğer tablo kilitlerini yok saymaz. Ayrıca kendi başına herhangi bir kilit oluşturmaz.

Büyük bir rapor oluşturduğunuzu veya büyük ve muhtemelen karmaşık bir SELECT ifadesi kullanarak veritabanınızdan veri taşıdığınızı düşünün. Bu işleminiz sırasında paylaşılan bir tablo kilidine yükseltilebilecek paylaşılan bir kilide neden olur. Diğer işlemler tablodan okunabilir, ancak güncellemeler mümkün değildir. Üretim tamamen durduğundan bu bir üretim veritabanı ise bu kötü bir fikir olabilir.

UNCOMMITTED READ kullanıyorsanız, masada paylaşılan bir kilit ayarlamazsınız. Bazı yeni işlemlerden sonuç alabilirsiniz veya verilerin nereye eklendiğine ve SELECT işleminizin ne kadar süre boyunca okuduğuna bağlı olmayabilir. Örneğin, bir sayfa bölünmesi oluşursa (veriler veri dosyasındaki başka bir konuma kopyalanacaktır) aynı verileri iki kez de alabilirsiniz.

Dolayısıyla, SELECT'inizi yaparken verilerin eklenebilmesi sizin için çok önemliyse, UNCOMMITTED'i OKUYUN mantıklı olabilir. Raporunuzun bazı hatalar içerebileceğini düşünmelisiniz, ancak milyonlarca satıra dayanıyorsa ve sonucu seçerken yalnızca birkaçı güncellenirse, bu "yeterince iyi" olabilir. Bir satırın benzersizliği garanti edilemeyebileceğinden, işleminiz hep birlikte başarısız olabilir.

SNAPSHOT İZOLASYON SEVİYESİNİ kullanmak daha iyi bir yol olabilir, ancak uygulamalarınızın bunu kullanmak için bazı ayarlamalar yapması gerekebilir. Bunun bir örneği, uygulamanızın başkalarının okumasını ve kullanıcı arayüzünde düzenleme moduna girmesini önlemek için bir satırda özel bir kilit almasıdır. SNAPSHOT İZOLASYON SEVİYESİ ayrıca önemli bir performans cezası ile birlikte gelir (özellikle diskte). Ancak sorunun üstesinden donanım atarak bunu aşabilirsiniz. :)

Bir veri ambarına veri raporlamak veya yüklemek için kullanmak üzere veritabanının bir yedeğini geri yüklemeyi de düşünebilirsiniz.

Basit bir tablo için, örneğin, mevcut satıra güncelleme yapılmadığı ve diğer tabloya hiçbir fk değerinin bulunmadığı, sadece eklenebilir bir denetim tablosunda kullanılabilir. Ek parça, geri dönüş şansı olmayan veya az olan basit bir ektir.

Şimdi her zaman OKUYU TUTULMADI kullanıyorum. En az sorunla hızlı. Diğer izolasyonları kullanırken neredeyse her zaman bazı Engelleme sorunlarıyla karşılaşırsınız.

Otomatik Artış alanlarını kullandığınız ve kesici uçlara para cezanızdan biraz daha fazla dikkat ettiğiniz sürece ve engelleme sorunlarına elveda diyebilirsiniz.

READ UNCOMMITED ile hata yapabilirsiniz, ancak dürüst olmak gerekirse, insertlerinizin tam kanıtı olduğundan emin olmak çok kolaydır. Bir seçimin sonuçlarını kullanan Ekler / Güncellemeler, dikkat etmeniz gereken tek şeydir. (Burada OKULULAN OKUYUN veya kirli okumaların soruna neden olmadığından emin olun)

Kirli Okumalara (özellikle büyük raporlar için) gidin, yazılımınız daha sorunsuz çalışacaktır ...