Sql Server 2014 performans problemi ve çözümleri

   Bir heyecanla taşındığımız 2014 ortamından çok şey bekleyorken hevesinizi kursağınızda bırakacak bir takım performans problemleri karşımıza çıktı.

Sql Server 2014 ile  birlikte  cardinality estimation yapısı yeniden yazıldı. Bu sebeple bazı sorgularda execution planlar çok farklı oluşup sürpriz performans kayıplarına neden olmaktadır.
Özellikle inner query, temp tablo içeren bazı sorgular ve case when içeren sorgular da daha çok rastladığım bir durum dur. 

Bi sürpriz yaşamamak için;
Öncelikle migration planınıza kritik sorgularınızın 2014 versiyonun da test edilip execution planının incelenmesini mutlaka ekleyin.

Bu gibi bir problem ile karşılaştığınız da öncelikle sp1 yüklümü kontrol etmek gerekiyor . Sp1 ile bu sorunların bazıları giderilmiş .
Bir de trace flag eklemek gerekiyor 1118 ve 1117 yi eklemek sorunlarınıza çözüm olacaktır.

Peki sp1 ve T-1118 T-1117 eklemek çözüm olmadı mı ?
Ozaman sorgu seviyesine inip  sorgunun hem eski cardinality de Hemde yeni cardinality de oluşan planını karşılaştırıp gerekli index force işlemi varsa yapabilirsiniz.
 Bu şekilde Manuel müdahale edilemeyen sorgular için ise  iş biraz daha karmaşıklaşıyor.
Ya database compatibility levelını eski versiyona çekerek çözüm üretilebilirsiniz, bu çözüm tercih edilmez. Bu 2014 ün nimetlerinden feragat etmişsiniz anlamına gelir, Karışık dediğim yanı bu dur.

Peki Manuel müdahale edecek çok yer var ve acil bir çözüm gerekiyor ise sadece sorgunuzu eski query planda çalıştırmak için  eski cardinality ile sorguyu derle diyebilirsiniz. Şu şekilde:
Sorgunun sonuna bir query hint tanımlayarak bu sorunu giderebiliriz.
...........
........... OPTION (QUERYTRACEON 9481);

Sql Server 2016 New Features

Bilindiği üzere microsoft sql ürün grubunda her 2 senede bir yeni versiyon çıkaracağını duyurmuştu. 2014 den sonra Sql Server 2016 versiyonu önümüzdeki sene release olacak. Yeni versiyonda neler gelecek bizi neler bekliyor diye merak edenlere bir kaç ipucu vermek istedim.

* Bomba özellik olarak tempdb yi artık çağaltabileceğiz. Her bir uygulama için ayrı tempdb kullanılmasına olanak sağlanacak. (CTP 2 de henüz bu özelliğe rastlamadım, sadece kurulum sırasında core adedi kadar tempdb datafile'ı oluşturmaya zorluyor.)
Aslında uzun zamandır böyle bir geliştirmeyi bekliyordum, sonunda geldi diyebiliriz.
Bu, şu demek oluyor, artık tek bir tempdb ye tüm instancenin yükünü vermek zorunda kalmayacağız, bir kaç tempdb farklı disklere farklı db ler için oluşturabiliriz. Bu tüm instance üzerindeki yükü tek bir database den geçirmeyip artık bir kaç dbye dağıtabileceğimiz anlamına geliyor ki, yıllardır uğraştığınız "tempdb yi ssd ye koy" derdinede bir nebze çözüm olacak.

* Tabi her zaman ki gibi cloud a daha fazla ağırlık verilmiş.

* Yeni bir özellik olarak In-memory table da in-memory oltp ile In-Memory DWH aynı tablo üzerinde kullanıbilme imkanı sağlanmış.
Bu da artık pratition table mantığı ile in-memory table tutabileceğimiz anlamına geliyor.

*  Bir başka iyileştirme hadoop tarafında, hali hazırda pdw de mevcut olan bir özelliğini sql server 2016 ya da getirmişler. Yani artık otomatik olarak sql server dan hadoop sorgulaması yapabileceğiz, üstelik ekstra bir map radius le uğraşmaya gerek kalmadan. Otomatik map radius  geliyor diyebiliriz.

*  Activity Monitor dashboard'ına yeni bir alan eklenmiş çok da güzel olmuş (ctp2 de ismini yazmayı unutulmuş) ACTIVE EXPENSIVE QUERIES tabı hayatımıza giriyor.

* Query Store özelliği artık hayatımıza girmiş olacak, (çok ihtiyaç duyduğumuz bir özellik) development ortamda sağlıklı çalışan querylerimizi productiona alırken execution planları ile alabilmemizi sağlayan bu teknoloji, aynı zamanda mevcut ortamda enable edildiği takdirde querye ait geçmiş planlarıda depolama şansı vererek, yeni query plan ile eskisini kıyaslama imkanı sağlamaktadır. Ve restart edildiğinde query planlar artık yok olmayacak.