Snapshot Isolation

MS SQL Server veritabanı ve SQL komutlarıyla ilgli sorularınızı sorabilirsiniz. Delphi tarafındaki sorularınızı lütfen Programlama forumunda sorunuz.
Cevapla
thelvaci
Kıdemli Üye
Mesajlar: 756
Kayıt: 11 Tem 2010 06:17
Konum: Istanbul
İletişim:

Snapshot Isolation

Mesaj gönderen thelvaci » 10 Ara 2012 08:19

Sql Server 2005+ veritabanı ortamlarında Snapshot Isolation transaction seviyesini kullanan arkadaşlarım varsa; tecrübelerini bizlerle paylaşmak isterler mi ? Serializable kadar güvenli, Read uncommitted kadar hızlı olmasını beklemiyorum ama production ortamında yaşadığınız tecrübelerden istifade etmek hoş olurdu elbette.

thelvaci
Kıdemli Üye
Mesajlar: 756
Kayıt: 11 Tem 2010 06:17
Konum: Istanbul
İletişim:

Re: Snapshot Isolation

Mesaj gönderen thelvaci » 14 Ara 2012 08:49

Gerçekten kimsenin snapshot isolation kullanmadığını düşünmek istemiyorum. Eminim "arkadaşlarımız mesajımı görmemişlerdir yahut meşgüllerdir" fikrine inanmak istiyorum.

Kullanıcı avatarı
Battosai
Üye
Mesajlar: 1316
Kayıt: 30 Eyl 2007 11:02
Konum: Ankara

Re: Snapshot Isolation

Mesaj gönderen Battosai » 15 Ara 2012 12:50

Snapshot Isolation
Bu ifadeyi bir çok kişi sayenizde görmüştür ne diyeceklerini bilmiyorlardır. Cevabı size kalabilir sorunuzun :)

thelvaci
Kıdemli Üye
Mesajlar: 756
Kayıt: 11 Tem 2010 06:17
Konum: Istanbul
İletişim:

Re: Snapshot Isolation

Mesaj gönderen thelvaci » 15 Ara 2012 01:07

Battosai yazdı:
Snapshot Isolation
Bu ifadeyi bir çok kişi sayenizde görmüştür ne diyeceklerini bilmiyorlardır. Cevabı size kalabilir sorunuzun :)
Yok canım o kadar da değildir ;) Bir kaç gün daha bekleyelim de bir kaç şey karalarız yanıt gelmez ise.

Kullanıcı avatarı
lazymule
Üye
Mesajlar: 127
Kayıt: 16 Eki 2006 03:03
İletişim:

Re: Snapshot Isolation

Mesaj gönderen lazymule » 15 Ara 2012 01:16

2. mesajın olmasını dilerdim fakat malesefe bir çok arkdaşımızın kullanmadığını düşünüyorum
hatta bir çoğumuz transactıon kullanmaya çok uzak olduğumuzu düşünüyorum.
kişisel tecrübem transactıon a giren çok kısa bir sürede geri dönüyor select le başlıyor sorunumuz
biz transactıon içinde seçince diğerleri kayda ulaşamıyor felan sorguları değiştirmek yada daha uyumlu yazmakta pek işimize gelmiyor
diğer bir pencere siz hız güven zaman gibi bileşenleri bir arada tutamıyorsunuz işinizi bir an önce bitirmeniz isteniyor yada istiyorsunuz.
connection - table yapısına biraz transactıonu hiç oturtamamışım dır. bde den sonra sql ile birlikte hep şunu yapmak istemişimdir
bir fatura kaydımız olsun kaydet e tıkladığımızda

transaction başlasın
fatura başlığı işlensinsin
fatura hareketleri işlensin
.... işlensin
sorun yoksa kayıtlar müdürlensin

sanırım rtti ile birlikte bu işlem yapılabilir orm - mvvm yapısıda olabilir.

kısaca hocam bizim sizin köye varmadan önce bir kaç köyümüzün daha olduğunu düşünüyorum.
biraz derine dalınca yeterli kaynak pek bulamıyoruz bulduğumuz kaynaklara ise yabancı dilimiz yetmiyor.
şu karalama kısmını hızlandırırsanız bizde sebepleniriz.
Evrende Ulaşılamayacak Tepe Yoktur !!!!
Yeterki İnsan Ulaşmak İstesin !!!!
http://www.maxiteknik.com

thelvaci
Kıdemli Üye
Mesajlar: 756
Kayıt: 11 Tem 2010 06:17
Konum: Istanbul
İletişim:

Re: Snapshot Isolation

Mesaj gönderen thelvaci » 15 Ara 2012 03:06

Bir DBA olmadığım için bu hususlarda asla ahkâm kesemem, bu sebeple bir sohbet havasında olsun istemiştim. Ama madem öyle dediniz, sohbete ben başlayayım sizler devamını getirin madem. Artık uzun sayılabilecek programlama hayatımda 1999-2000 senesine kadar, iyi derecede veritabanı programlama bildiğime inanırdım. Taki o sene hiç bir şey bilmediğimi anlayana kadar. O zamana değin kullandığım veritabanlarını sadece veri depolamak ve istediğim an veriyi geri çekebilmek adına kullanırdım.

Veri tabanı normalizasyonunun ne olduğundan, indexlerin, istatistiklerin, stored procedure'lerin, triggerların, jobların, foreign key'lerin, check constraintlerin ve özellikle de transactionların ve bunların isolation seviyelerinin ne olduğunu bilmeden mutlu mesud bir programlama hayatım vardı. Elbet bu hususlarda bir kulak dolgunluğuna sahiptim; ama önem derecesinin yüksekliğine vakıf olmadığım için de son derece rahat bir şekilde OOP ile temaşam devam ediyordu.

Ancak, ne zamanki tasarladığımız bir veritabanını yüzlerce insan yoğun bir şekilde kullanmaya başladı, işte o noktada da sorunlar başladı. Aslında buna sorun dememek lazım, insanları bilgiye iten sorunlara kötü diye bakmıyorum ben, aksine iyiki o sorunları yaşamışım diyorum şimdi.

Maalesef bütün dünya genelinde, büyük oranda programcıların üstündeki yük balans edilmiş değildir. Ya bir kişinin kaldırabileceğinden fazla iş bir programcının sırtına yülenmiştir yahut bir kişinin yapabileceği bir iş bir ekibe ihale edilip işin daha da uzamasına neden olunmuştur. Bunun ortasını yapan, uygulayanlar elbette vardır lâkin bu seviyede profesyonel çalışma ortamlarının son derece nadir olduğunu düşünüyorum. İşler bu ahvalde olunca, her biri bir uzmanlık gerektiren mesleki branşları bir kişi yapmak zorunda kalıyor ve dolayısı ile her şey de ister istemez yarım yamalak oluyor. İnsan doğası gereği her şeyi bilmemiz mümkün olmadığı için, en iyi olduğumuz sahada kayda değer bir iş ortaya çıkartabiliyoruz ancak zayıf olduğumuz kısımda çıkarttığımız iş, toplam faydada azalmaya neden olabiliyor.

Ülkemizde ve dünyada; işi direkt bilişimle alakalı olan sektörler özellikle, çeşitli baskılardan mütevellit ürünlerinin arkasındaki veritabanı konusunda bazı kaygılara sahip olabiliyorlar. Bu kaygılar; ürünün birden fazla veritabanı tipine destek vermesi ile başlıyor aslında. Her daim yönetim kademesi, satacakları ürünün pek çok veritabanına sorunsuz destek vermesini ister. Bu; her müşterinin daha önce satın almış olabileceği farklı bir veritabanı olması durumunda, ürünün o müşteriye de hitap edebilmesi dolayısı ile satılabilmesi için, patronların özellikle olmazsa olmaz defactolarından birisidir.

Böyle bir istekle diretilen programlama ekibi; belirli bir deadline'a sahip olmaları ve birden fazla da veritabanına destek vermeleri gerektiği kendilerine dikte edildiğinden işin en kolayı olan; uygulama içinde SQL kodlama tercihine kaymak durumunda kalıyor ister istemez. Böylece, kullandıkları veritabanlarının kendisine has güçlerinden asla istifade etmeden, hepsinin ortak özellikleri ile yetinmek durumunda kalıyorlar. Tıpkı evi ile işi arasındaki mesafe 5 km olan bir çalışanın işine geç kalmamak istemesinden yada yürümek istemememesi nedeni ile bir Ferrari araba alması gibi. Sadece işten eve, evden işe gitmek için hele hele 5 km gibi kısa bir mesafeyi gitmek için bir Ferrari araba almak ne kadar mantıklı ise, veritabanlarının barındırdıkları özellikleri kullanmadan sadece dört tekerleği ve koltuğu olsun bana yeter diyerek kullanmak da aynı derecede mantıklıdır.

Tecrübelerim bana veritabanlarının güçlerinin sonuna kadar kullanılması gerektiğini öğretti. Bunun nedenlerini yazmaya kalksam eminim sayfalar dolusu olacaktır. Belki sohbetin ilerleyen aşamalarında daha derinlemesine irdeleriz. Veritabanları üzerindeki her bir tablo tasarlanırken her tablonun en azından bir clustered unique index'e sahip olması gerektiği, clustered seçilecek index'in o tablodaki non-clustered indexlere ciddi etkilerinin olduğu, çok fazla DML işlemi gören tablolar üzerinde index tanımlarken bir kaç kere düşünmek gerektiği, sistemlerin başlangıçta hep hızlı olduğu ama DML işlemlerinden sonra ilerleyen zamanlarda kesinlikle yavaşlayacağı dolayısı ile index bakımlarının ara ara gözden geçirilmesi gerektiği, veri kaybının tahammül edilemez, tahammül edilmemesi gereken bir kavram olduğu, en az veri kaybı kadar veri tutarlılığının önemli olduğu, ilişkili tablolar üzerinde kesinlikle foreign key kullanılması gerektiği, belirli değerlerin dışına çıkamayacak kolonlar için kesinlikle check constraint kullanılması gerektiği ve belki de en önemlisi business logic denen iş mantığının kesinlikle veritabanı üzerinde kodlanması gerektiğini zamanla ve tecrübe ederek öğrendim.

Hepsinin kendince detaylı ve anlamlı açıklamaları var. Ancak bir sohbete başlangıç için bu detaylar yorucu ve belki de sıkıcı olabilir. Tüm bu bilgilerin ışığında, malumunuz odur ki SQL Server üzerindeki transaction isolation seviyeleri de performans ve kilitlenme konularında bizim en büyük yardımcılarımızdan birisi. Hiç kimse, gerek programcı gerekse de kullanıcı, kullanılan ürünün yavaş çalışmasına tahammül edemez. Ama bundan da önemlisi, uygulamanın hatalı çalışmasına ise hiç tahammül edemez. SQL Server'da varsayılan olarak read committed isolation seviyesi kullanılmaktadır. İşte bu isolation seviyesi nedeni ile bazen patron raporları adını verdiğimiz raporlar SQL Server'da belli başlı tabloların kilitlenmesine ve o raporun bitmesine kadar diğer kullanıcıların beklemesine dolayısı ile sistemin yavaş çalışmasına neden olur. Isolation seviyeleri çok derin ve benim kendimi bu hususta yeterli hissetmediğim konulardan birisi dolayısı ile çok fazla derin malümatlar veremem, vermeye çalışır isem işi DBA olan arkadaşlarıma haksızlık etmiş olurum. Ama kısaca; SQL Server tarafında her türlü problemin önüne geçilebilmesi için kilitleme mekanizmalarının(lock) kullanıldığını söyleyebilirim. Isolation seviyeleri veritabaı tarafında bu kilitleme mekanizmalarını yönetirler. Her isolation level belli başlı bazı problemlerin önüne geçebilir. Veritabanı ortamlarında pek çok sorun olabilir. Bunlardan başlıcaları, Dirty reads, non repeatable reads, phantoms ve lost records sayılabilir. Bunlarla alakalı detaylı bilgileri Google'dan elde edebilirsiniz.

SQL Server'ın varsayılan isolation leveli olan read committed ikinci seviye izolasyon seviyesidir. Bunun bir altında read uncommitted isolation seviyesi bulunur. Bunun haricinde repeatable read, serializable ve SQL Server 2005 den itibaren snapshot isolation seviyeleri de vardır. Serializable isolation level, isolation levellerin en katısıdır. Bu seviye isolation level de veritabanı üzerindeki verinin tutarlılığı garanti edilir. Ne dirty read, ne non repeatable read ne phantom ne de lost records problemleri oluşmaz. Ama her iyi şeyin bir bedeli olduğu gibi bu seviye izolasyonun da daha fazla kilitlenme dolayısı ile kullanıcıların daha fazla blok olması durumlarına neden olduğunu söylemek gerekir.

İşte Snapshot isolation level tamda burada devreye girer ve gerçekten de hayat kurtarıcıdır. Yukarıda sayılan problemlerin çok büyük çoğunluğunu engellediği gibi aynı zamanda kullanıcıları da bloke etmez ! Özetle, veritabanınız üzerindeki her bir DML işlemi için TempDB tarafında versiyonlama sistemine dayalı bir mekanizma ile çalışır. Dolayısı ile tempdb veritabanı bir müddet sonra çok şişmeye başlar, ancak tempdb veritabanınızı bir başka diske alıp her gece de gerekli veritabanı bakım joblarını çalışıtırırsanız mükemmel bir çözüm olacaktır.

Tabii bunlar benim bilgilerim. Bu seviye izolasyonu henüz çok fazla deneme imkanına sahip olamadım. Bu nedenle sohbet etmek ve test etmeye fırsat bulan arkadaşlarımız ile fikir teatisinde bulunmak istedim. Buyrun giriş kısmını ben yaptım, sözü sizlere bırakayım :)

thelvaci
Kıdemli Üye
Mesajlar: 756
Kayıt: 11 Tem 2010 06:17
Konum: Istanbul
İletişim:

Re: Snapshot Isolation

Mesaj gönderen thelvaci » 19 Ara 2012 10:30

Çok mu sıkıcı yazdım nedir ;)

mkysoft
Kıdemli Üye
Mesajlar: 2815
Kayıt: 25 Ağu 2003 11:35
Konum: İstanbul
İletişim:

Re: Snapshot Isolation

Mesaj gönderen mkysoft » 18 Oca 2013 12:23

gayet güzel olmuş, teşekkürler.

Bay_Y
Üye
Mesajlar: 77
Kayıt: 10 Mar 2014 11:12
Konum: İstanbul

Re: Snapshot Isolation

Mesaj gönderen Bay_Y » 27 Kas 2017 03:13

Eline diline sağlık gayet güzel olmuş. Bu konuda hala yeterli bilgi türkçe olarak internette bulunmamakta , bilgili arkadaşlar bu konuda yardımcı olabilirse çok sevindirici olacağı kanısındayım.

Teşekkürler.

Cevapla