NOLOCK Kullanımı Hakkında

[Berke Sokhan]

Selamlar,

Bu konunu kaynaklandığı post aslında başka bir konu hakkında idi dolayısıyla thread-theft yapmayalım diye buradan devam etmk üzere bu mesajı atıyorum...

Pamir Erdem en son şunu yazmıştı:

Merhaba

Sistemde nolock kullanmak  sizin tasarımınızda hata vardır anlamında değildir farklı yere data atmak zorunda kalırsınız. Eninde sonunda bir yerlerde nolcok kullanırsınız bunun oracle mssql ile de alakası olmadığını düşünüyorum. Sonuçta tablo tasarımınızda denormalizasyon yapmaya başlarısınız bu da I/O costunuzu arttırabilir.  Şuan en büyük gördüğüm Internet Bankacalığında 5 TB data mız vardı çoğu tablomuzun 2 milyardan fazla datası vardı ve bazı noktalarda tabloların update edilmesi gerekiyordu mission critic yerler dışında hiç bir yerde nolock kullanmamazlık etmedik.  Kısaca demeye çalıştığım şey bunu nolock kullanmak tasarım hatasıdır demek biraz yamlış olur

Genel olarak hala nolock kullanımını bir tasarım smell i olduğunu düşünüyorum... Biraz daha açıklık getrimek gerekirse,

Birinci durumda, siz insert-update yaptığınız bir DB tablosunda aslında (belki de raporlama amacıyla) genelde select kullanacağınız bazı bilgileri gömmüş olabilirsiniz.. Yani dediğiniz gibi performans amacıyla tablolarınız bazı noktalarda denormalized dır. O zaman tx içine dahil olan veriler ile dahil olmayan verileri birlikte çekiyorsunuzdur, bu sebeple dirty read (veya read uncommitted) a yol açıyorsunuzdur. Bu pek kabul edilebilecek bir durum değildir.

İkinci durumda ise, evet, ilk örneğinizdeki gibi devamlı insert ve update ler ile meşgul olan bir tabloda aslında bunlara hiç katılmayan ve lockları göz ardı ederek okuyabileceğiniz bazı verileriniz olabilir.. Ama bu durumda ise o zaman DB deki tablo tasarımınız yanlıştır aslında nomalize edilmelidir. NOLOCK kullanmanıza da gerek olmaz.

Son olarak ise bunları sizi hedef alarak söylemediğimi hatırlatmak isterim. Genel bir durum için genel bir davranış patterni olarak bahsettiğimi ve Fowler ın da belirttiği gibi aslında tx lerin domain in önemli bir parçası olduğunu ve ek olarak context in de king olduğunu ekliyim :))


İyi Çalışmalar,
--
Berke SOKHAN

[Pamir Erdem]

Merhaba 

Öncelikle kesinlikle kişisel olarak üzerime alınmadığmı söyliyelim. Sonuçta burası teknik olarak tartışma yeri : )

1. Normalizasyon dediğiniz zaman tekrarlanan data olmamaası gerekli. genel olarak da 3NF'de ileri de gitmek performans sorunu yaratbilir.

2. 3 NF'e uygun bir şekilde dizayn edilmiş bir tabloyu tekrar bölmek ve bu datayı sürekli bi tablodan update edilecek yere kopyalamak çok specific caseler dışında bir anlamı yoktur.

3.  Her doğru tasarım performance'lı olacak diye bir kaide olmadığı gibi de 3-4 TB'lik tek bir Database üzerinde 1ms'nin bile önemi olduğunu ve yazılan mission critic yerler dışında nolock kullanılmasını tavsiye ederim ben bulunduğum projelerde böyle yapıyorum tasarım dediğiniz şey felsefe olduğu için herkesin düşüncesi kendine tavsiye olarak da 

4. Martin Fowler'ın kitabın EAP'da her söylediğini harfine yapmak zorunda deilsiniz sizin caseleriniz size uygundur ama çoğu case'de sizi kurtarır : )

http://download.microsoft.com/download/1/3/4/134644fd-05ad-4ee8-8b5a-0aed1c18a31e/TShootPerfProbs.doc okumanız yararlı olacaktır diye düşünüyorum. burda nolock dan çok az bahsediliyor ancak .çok güzel bir dökümandır herkesin okumasunda da fayda görüyorum. 

Saygılarımla

Pamir

[Pamir Erdem]

Selam Berke 

Softtech'den Umut Esen'i tanıyor musun bir de Orhan la çalıştın mı Turkcell'e geçen ?

[Berke Sokhan]

Selam Pamir,

Orhan Mülayim'di sanırım di mi? gözlüklü esmer... O ise eğer kısa bir süre çalıştım evet, bizim IBM Process Server ımız ve SOA yapılarıyla ilgilenen ekipteydi, tanıyorsan selam söyle... :)) (Safir Service Provider dan Berke dersin :P )

Umut Esen'i kişisel olarak tanımıyorum ama kurumsal portalımızda bizim şirkette çalıştığını gördüm, dahası için yorum yok :)

Aşağıda madde madde cevap vermeye çalıştım:

1. Normalizasyon dediğiniz zaman tekrarlanan data olmamaası gerekli. genel olarak da 3NF'de ileri de gitmek performans sorunu yaratbilir.

* ok.

2. 3 NF'e uygun bir şekilde dizayn edilmiş bir tabloyu tekrar bölmek ve bu datayı sürekli bi tablodan update edilecek yere kopyalamak çok specific caseler dışında bir anlamı yoktur.

* ok.

3.  Her doğru tasarım performance'lı olacak diye bir kaide olmadığı gibi de 3-4 TB'lik tek bir Database üzerinde 1ms'nin bile önemi olduğunu ve yazılan mission critic yerler dışında nolock kullanılmasını tavsiye ederim ben bulunduğum projelerde böyle yapıyorum tasarım dediğiniz şey felsefe olduğu için herkesin düşüncesi kendine tavsiye olarak da

* ok ama tasarım kriterlerinde performans varsa not ok. :))
* bizim de benzeri bir sistemimiz oldu nolock kullandığımız, şöyleki türkiyenin en çok (veya ilk 3 diyim) ziyaret edilen gazete sitesini ve bununla ilgili ilan sitelerinde (emlak, araba) NOLOCK kullanmak durumunda kullandık. Ancak dediğim gibi context is king olmasına rağmen yine de tabloları daha sıkı inceleyip NOLOCK kullanımından kaçabilir miydik diye sorarım hala... Senin case inle ilgili DB entitylerine bakarak üzerinde konuşmak gerek bence...

4. Martin Fowler'ın kitabın EAP'da her söylediğini harfine yapmak zorunda deilsiniz sizin caseleriniz size uygundur ama çoğu case'de sizi kurtarır : )

* Yapmadık zaten :)) Sadece bir ilke alıntısı yaptım, transactionlar için genel geçer bir kural koymak yerine transactionın domain içindeki yapısını inceleyip ona göre karar verilemesi gerektiği ile ilgili....

İyi Çalışmalar,
Berke SOKHAN

[Berke Sokhan]

Pamir, şimdi ben de senin çalıştığın yeri gördüm :))

O zaman hemen sorayım:

Veysel Taşçıoğlu nu tanıyor musun?
Selçuk Yavuz'u tanıyor musun?

öyleyse selam :P

(konu dağıldı mı ne :D)

2009/2/11 Berke Sokhan <berke...@gmail.com>

--
Berke SOKHAN

[Tuna Toksoz]

Beni tanıyan var mı?

Tuna Toksöz
http://tunatoksoz.com
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/2/11 Berke Sokhan <berke...@gmail.com>

[Berke Sokhan]

ben duymuştum seni... sen şu kış uykusu ile ilgileniodun di mi? national geographics den? :))

2009/2/11 Tuna Toksoz <teh...@gmail.com>

--
Berke SOKHAN

[Murat Ozgur KAYMAKCI]

merhaba,

nolock konusu genelde tartışılması çok sevilen bir konu :) zamanında ben de nolock kullanılıyorsa bu işin içinde bir pislik var dediğim çok olmuştur, dirty read 'lerden dolayı. mesela bir tablo tasarımı yapıyorsunuz süper normalize fakat birgün geliyor sizden öyle bir rapor istiyorlar ki mecburen nolock kullanıyorsunuz çünkü tasarım buna müsait değil, tasarımı değiştireyim diyorsunuz ama 1.5tb veri olmuş değiştirmek tam bir işkence ve dba kapı gibi karşınızda duruyor. böyle durumlarda yaşasın nolock diyorsunuz :)

2009/2/11 Berke Sokhan <berke...@gmail.com>

[Sidar Ok]

nolock kullanimi bi design smell dir.

SQL 2005 de snapshot isolation level kullanilir, sorun cozulur hayat bayram olur.

2000 de, belli bir cozum yoktur, ama berkenin i$aaret ettigi durum %80 ba$ima gelen $eydir. QUery ler optimize edilir, bazi tablolar bolunur (ovunme 3NF'm senden buyuk BCNF var )

Live data dan report cekmek online kullaniciya yapabileceginiz en buyuk pisliktir zaten.

Illa ki NOLOCK cekmem gerekti, baktim ba$ka care yok - en azindan cektigim kayit sayisini minimalde tutmaya cali$irim. Standardim 1 page i gecmeyeyim $eklindedir.

2009/2/11 Murat Ozgur KAYMAKCI <murat...@gmail.com>

--
Sidar Ok
http://www.sidarok.com

[Tuna Toksoz]

SQL 2005 de snapshot isolation level kullanilir, sorun cozulur hayat bayram olur.

mis :)

Tuna Toksöz
http://tunatoksoz.com
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/2/11 Sidar Ok <sid...@gmail.com>

[Sidar Ok]

ayrica messaging ve sagalar yuzyilinda, nedir hala bu lock problemi di mi azizim

2009/2/11 Tuna Toksoz <teh...@gmail.com>

[Tarik Kranda]

Mis derken ne tarz bir mis Tuna:))  Hadi birkaç kere daha düşünüp!!! fonksiyonel bağımlılık diyagramlarını da oluşturduk ve Boyce Codd normalizasyona kadar dağılımı sağladık. Fakat gene de elimizdeki bazı tabloların boyutu çok büyük olduğundan özellikle log işlemleri olan tablolarda, insert sayımız çok fazla olduğundan veya anlık online işlemleri izlemek için kullandığımız geçici tablolarda sadece select atmamız gereken durumlar olabilir, ki iş kurallarını ne kadar sorgulasanız da oluyor bu malesef. Bu durumda Snapshot isolation level kullanmadan önce birkaç kere daha düşünmek gerekiyor bence. Getirdiği performans yükü oldukça fazla zaten ve sağlam update alan tablolarda tempdb'yi oldukça şişiriyor, bir de versiyonların temizlenmesi için ek bir yük getiriyor OLTP işlemlerde. Benim merak ettiğim konu, ben bir rapor alırken dirty read oluşsa, phantom readler olsa bundan ne kaybım olabilir ki acaba? Alt tarafı bir rapor ve transaction log bottleneck'ine de takılmadan, lock escalationa sebep olmadan yapsın işini çıksın gitsin tablomuzdan yaw:)). Yani nolock 'ı burada neden kullanmayayım ya da kayıt sayımı neden bir page ile kısıtlama yoluna gitmeliyim, burda bir bilgi eksiğimiz olabilir, birisi izah edebilirse sevinirim cidden:))

Aramızda mission critic bir işlem yapmayan ve nolock'tan dolayı herhangi bir veri ya da performans kaybına uğramış olan var mı, case i bizle paylaşırsa sevinirim:)

Bir de Pamir, Tuna' nın criteria üzerindeki SetLockMode opsiyonu cidden güzel, buna ek olarak bir de bu iş, oturuma ait connection seviyesinde bağlantının TransactionIsolationLevel 'ını TRANSACTION_READ_UNCOMMITTED' a set ederekte halledilebilir mi acaba? Yoksa connection nesnesine ait bu method NHibernate tarafında yok mu? VPN 'e bağlanamadığım için deneyemiyorum şu anda. (SetTransactionIsolation)

session.connection().setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

Herkese iyi geceler.

Tarık KRANDA

11 Şubat 2009 Çarşamba 22:45 tarihinde Tuna Toksoz <teh...@gmail.com> yazdı:

[Tuna Toksoz]

gordugu en buyuk veritabani Adventureworks olan insana bu yapilmaz :)

Tuna Toksöz
http://tunatoksoz.com
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/2/12 Tarik Kranda <tarik...@gmail.com>

[Tuna Toksoz]

Transaction modu set edilir de simdi su query hint olayina insalalh ilerleyen versiyonlarda degineceiz once bi AST yapisi ciksin ustune on bin takla attirilir merak etmeyin.

Tuna Toksöz
http://tunatoksoz.com
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/2/12 Tarik Kranda <tarik...@gmail.com>

[Pamir Erdem]

Akılda bulunması açısından SnapShot Isolation level bvest practicelerde ve gördüğüm projelerde asla Prod ortamında çalıştırılmaz sadece dev ve test ortamlarında izin verilirki developerler çalışırken diğerleri etkilenmesin
bunu kullanmak perf kaybıdır.

[Sidar Ok]

online heavy transaction lar yapan, geni$ bandwidth yuku altinda bulunan ve sinirli stresli bi projemde $u an snapshot isolation level kullaniliyor.

Memory sorunu ya$ariz diyen architect e yemek ismarlatmamla son bulmu$ olan bu tarti$ma icin, istedigim tek $ey bi fact sheet dir.

Tarik sana daha geni$ bi zamanda yazicam cevap :)

2009/2/12 Pamir Erdem <pamir...@gmail.com>

Akılda bulunması açısından SnapShot Isolation level bvest practicelerde ve gördüğüm projelerde asla Prod ortamında çalıştırılmaz sadece dev ve test ortamlarında izin verilirki developerler çalışırken diğerleri etkilenmesin
bunu kullanmak perf kaybıdır.

[Pamir Erdem]

Sidar bi ara yemeğe gidersiniz ama ben de kullanmam o zaman bana da ısmarla geldiğinde

tempdb bottleneck diye troubleshooting perf. sql srv 2005 de geçio sanırım bu orda okumak gerekli

[Sidar Ok]

ismarlariz ayipsin.

link olursa okuyan bi insanim ben.

2009/2/12 Pamir Erdem <pamir...@gmail.com>

Sidar bi ara yemeğe gidersiniz ama ben de kullanmam o zaman bana da ısmarla geldiğinde

tempdb bottleneck diye troubleshooting perf. sql srv 2005 de geçio sanırım bu orda okumak gerekli

[Tuna Toksoz]

sidar anca ordan buraya pizza siparis eder :)

Tuna Toksöz
http://tunatoksoz.com
http://twitter.com/tehlike

Typos included to enhance the readers attention!

2009/2/12 Sidar Ok <sid...@gmail.com>

[Pamir Erdem]

abi pizza demeyein lütfen kustum geçen yıl onun yüzünden 

dün linki yollamıştım maillerde vardı ama gene altını çiziim emin deilim  orda yazıpğ yazmadığında sadece orda okuduğumu hatırlıyorum onu detaylıca araştırım yarın ya da öbür gün maille beraber nedenlerini yazarım

[Tarik Kranda]

Eyvallah Sidar:))

İyi geceler.

Tarık

12 Şubat 2009 Perşembe 01:26 tarihinde Sidar Ok <sid...@gmail.com> yazdı: