• Web sitemizin içeriğine ve tüm hizmetlerimize erişim sağlamak için Web sitemize kayıt olmalı ya da giriş yapmalısınız. Web sitemize üye olmak tamamen ücretsizdir.
  • Sohbetokey.com ile canlı okey oynamaya ne dersin? Hem sohbet et, hem mobil okey oyna!
  • Soru mu? Sorun mu? ''Bir Sorum Var?'' sistemimiz aktiftir. Paylaşın beraber çözüm üretelim.

Sql Server 2014 Cardinality Estimator

Üyelik Tarihi
24 Mar 2017
Konular
1,018
Mesajlar
2,425
MFC Puanı
4,910
Kullandığımız SQL 2012 database lerden birini yeni kurmuş olduğumuz SQL 2014 Always On server a taşıdık. Daha sonra yaptığımız testlerde ise yeni sistemin konfigurasyonunun(CPU, RAM, Ve diğer SQL SERVER best practice lerinin uygulanmış) çok daha iyi olmasına rağmen özellikle bir tabloya insert işlemi yaparken çok daha uzun sürdüğünü hatta zaman zaman Timeout hatasına düştüğümüzü fark ettik. Insert işlemi yapılmaya çalışılan tabloda yaklaşık olarak 1.500.000 kayıt bulunmaktaydı ki, aynı transaction SQL 2012 server da yaklaşık olarak 1 sn civarında gerçekleşirken. Aşağıdaki ekran çıktısından da execution planı görebilirsiniz.
d146ee66-3989-4d0a-b9d8-6c9a4dc9c732.png


SQL 2014 server da yaklaşık olarak 1.5 dakika civarında sürüyordu. Bir an için acaba SQL 2014 Always on 2 sync replica ve 1 Async replica olması nedeniyle network tarafında bir sıkıntımı olduğunu araştırdığımızda ise herhangi bir network problemi olmadığını anladık. insert işleminin yeni yapıda daha uzun süreceğini hesaplıyorduk ancak bu kadar sürmesi kabul edilemezdi.
9f410c60-a2a7-453b-8609-8422f6ad40d1.png


Daha sonra yaptığım detaylı incelemede insert yapılan tablodan başka birde yaklaşık olarak 45.000.000 kaydın olduğu diğer bir tablo daha bulunduğunu ve bu iki tablonunda Indexed view oluşturularak join edildiğini buldum.
Sorun da tam olarak bu noktada başlıyordu çünki execution plana göre insert işlemi için büyük tabloda Index scan işlemi yapılıyor bu da çok uzun zaman sürüyordu. Peki SQL 2014 neden böyle bir execution plan oluşturuyordu SQL 2014 ile birlikte Cardinality Estimator ın yeniden geliştirildiğini ve yeni versiyonun daha efektif çalıştığını önceki tecrübelerimden biliyordum ancak belki de Indexed View’ler ile ilgili bir bug olabilirdi ancak internette yaptığım araştırmalarda böyle bir bilgiye ulaşamadım.
Şimdi ise önümde sorunu çözmek için 2 yol kalıyordu
1. Eski Cardinality Estimator I kullanmak
2. Indexed View’i drop edip tekrar normal View oluşturmak

1.Opsiyon ekran çıktısı.
a532f2a9-5f71-4a6f-a37f-d6c882a6c347.png

2.Opsiyon ile ilgili ekran çıktısı
a532f2a9-5f71-4a6f-a37f-d6c882a6c347.png


1.Opsiyon daha kolay gibi görünsede bence Yeni bir arabaya eski bir motor takmak gibi birşeydi.
bu nedenle bu Indexed View’I kullanlanan tüm sorguları inceleyerek zaten best practice olmayan OLTP sistemlerinde Indexed Viewin drop edilerek tekrar normal View olarak create ettim. Aynı Insert işlemini yaptığımda ise tam olarak istediğimiz gibi çalıştığını ve insert işleminin tekrar 1 snin altında ve daha az IO yaptığının sağlanması ile sorun çözülmüş oldu.
 
Üst