Performance Tuning

SQL Server, Performans Ayarlama nedir?

Mevcut T-SQL sorgularının alınması ve daha hızlı çalışmasını sağlayacak şekilde değiştirilmesi işlemidir.

SQL Server Yavaşlık Örnekleri

• Bir uygulamanız var ve uygulamanın yanıt vermesi çok uzun sürüyor.
• Bir SQL Server’ınız var ve Performans Monitörüne baktığınızda CPU’yu %100 olarak gösteriyor.
• SQL Agent işleri zamanında bitirilemiyor veya üretime ya da yüksek kullanımlı pencerelere taşmaya başlıyor.
• Raporların işlenmesi çok uzun sürüyor. Ya da hiç bitmiyor.
• T-SQL bir parametre setiyle hızlı çalışıyor, ancak diğerleriyle yavaş veya hiç tamamlanmıyor.
• Çok daha fazlası…

Çoğu zaman duyduğumuz şey “Bu daha önce hızlıydı (veya iyiydi), ama şimdi oldukça lyavaş”.

Yavaş SQL Birkaç Şekilde Ortaya Çıkar

• T-SQL daha önce hızlıydı ve giderek yavaşladı.
• T-SQL her zaman yavaştı (veya hiç hızlanmadı).
• T-SQL daha önce iyiydi, ancak bir değişiklikten sonra (genellikle ilgisiz görünen) SQL yanıt süresi çok yavaşlattı.

SQL Server’ın Yavaşlamasının Nedenleri

İşte sahada en sık gördüğümüz birkaç neden:

1. Kötü Sorgular. Ya eski sorgular yavaşlar ya da yenileri, mevcut SQL Server kaynaklarının tamamını kullanır ve diğer sorguları kaynak sıkıntısı içinde bırakır.
2. Sorgular çok karmaşıktır. Buna iyi bir örnek, 30 birleştirme ile 5 sayfa uzunluğunda devam eden bir sorgudur. Bunu yapmanın daha kolay yolları vardır.
3. Üretim SQL Server’ında raporlama sorguları çalıştırmak. SSRS, SSIS ve veri ambarını alıp aynı sunucuya yerleştirmek başlangıçta mantıklıdır. Ancak daha sonra bu SSRS raporları gerçek üretim sorgularıyla rekabet etmeye başlar. Yani şimdi finans departmanındaki Jale 5 yıl öncesine bakan bir rapor çalıştırıyor ve tüm SQL Server kapasitesini e-ticaret mağazanızdan bir şeyler satın almaya çalışan Hakan’ın elinden alıyor. Bu hiç iyi değil.
4. Sorgular kodla yazılır. Bu genelde işe yarar. Zamanın %95’inde. Ve sorun da bu. Çünkü yavaşladığı zamanlar acı şekilde hissedilir.
5. Kötü İndeksleme. İndeks eksikliği, çok fazla indeks, yanlış sütunlardaki indeksler, yinelenen indeksler, neredeyse yinelenen indeksler, birleştirilebilen indeksler, eksik indeks uyarıları ve bakım maliyeti yardımcı olduklarından daha yüksek olan indeksler.
6. Hatalı Mimari ve Kötü Veritabanı tasarımı. Tek bir veri dosyası ile kurulmuş bir veritabanı buna iyi bir örnektir. Hızlı olması gereken önemli veri tabanları, birden fazla dosya grubuna ve dosyaya sahip olmaktan, yükü birden fazla sürücüye yaymaktan ve hangi tablo ve dizinin hangi dosyaya gideceğini stratejik olarak seçmekten çok şey kazanabilir.
7. En İyi SQL Server Yapılandırma Uygulamalarının Eksikliği. Win OS, Grup İlkesi, Active Directory, SQL Örneği Ayarları, veritabanı ayarları vb. birçok yerde ayarların değiştirilmesi gerekir.
8. İyi bir SQL Server Bakım Planı eksikliği. Bu durum yedeklemeleri, dizin bakımını, istatistik bakımını vb. etkiler. Ve evet, sorgular her hafta %10-20 daha yavaş çalışmaya başlayabilir ve 6 ay sonra her şey sürünmeye başlar.
9. SQL Server’a RDP ile bağlanmak. RDP kulağa zararsız geliyor. Ancak birinin RDP’ye bağlandığını, Visual Studio’yu başlattığını ve SSIS paketleri üzerinde çalışmaya başladığını düşünün. Bu, önemli boyutlarda RAM ve CPU’yu kolayca tüketebilir. Ve Win OS performans ölçümlerini de izlemediğiniz sürece bu faaliyetler SQL Server izlemenizde bile görünmeyecektir.
10. Veri Boyutu. Veriler zaman içinde büyüdü ve artık SQL başlangıçta tasarlandığı gibi birkaç bin yerine milyonlarca veya milyarlarca satırı işliyor.
11. Kod Dağıtımı. Kod dağıtımından sonra işler yavaş çalışmaya başladı.
12. Altyapıdaki Değişim. Depolama, ağ veya sanal makine değişiklikleri buna iyi bir örnektir. Bu genellikle tüm sorguların yavaşlamasına neden olur. Teşhis etmek zordur, çünkü “SQL Server’da herhangi bir şey değişti mi?” diye sorarsanız cevap “Hayır” olacaktır.
13. Arızalı Donanım. Depolama veya ağ gibi belirli donanım arızaları SQL Server’ı bozmaz, ancak sunucunun aynı işlemi birkaç kez yeniden denemesine neden olarak işleri yavaşlatır.
14. Ve Daha Birçoğu…

Yavaş SQL Türleri

SQL iki şekilde gerçekleşir:

1. Yavaşlığı yakalamak kolaydır. Uygulama ekranının eskiden yarım saniye sürdüğünü biliyorsunuz ve şimdi 2 dakika oldu ve hala dönüyor ve bitmedi.
2. Yavaşlığı yakalamak zordur. Sorgu eskiden 4 dakika 37 saniye sürerken şimdi 6 dakika 11 saniye sürüyor. Böyle bir şeyi yakalamak için iyi bir SQL Server İzleme sistemine sahip olmanız gerekir.

SQL Server Yavaşladığında Atılacak Adımlar

SQL Server’ı veya Windows işletim sistemini henüz yeniden başlatmayın. Önce biraz veri toplayın. Yoksa yavaşlığın neden olduğunu bilemezsiniz. Ya da sorgu_1’den şüpheleneceksiniz, ancak suçlu olan sorgu_7 olacak. Bu da yavaşlık sorununun tekrar yaşanacağını garanti eder.

SQL’in neden yavaş çalıştığını daraltmak istiyorsunuz.

Cevaplamak istediğiniz birkaç soru var:

1. Şu anda engellenen herhangi bir T-SQL var mı?
2. Uzun süredir çalışan veya çok fazla kaynak tüketen T-SQL var mı?
3. Açık olan ve hiç kapanmayan işlemler var mı?
4. Bir sorgu mu yavaş, yoksa her şey mi yavaş (muhtemelen sistem genelinde bir değişiklik söz konusu)?

Cevapların ne olduğuna bağlı olarak, ideal olarak kullanılan gerçek parametrelerle birlikte tam bir T-SQL çağrısına kadar daraltmak istersiniz.

Ayarlama Hataları

1. Çok hızlı yeniden başlatma. Bu, yarattığı birden fazla sorun nedeniyle yapabileceğiniz en kötü şeylerden biridir. a) düzgün bir şekilde incelendiğinde sorunun nerede olduğunu gösterecek pek çok güzellik içeren tüm SQL veri toplama (DMV) tablolarını temizlediniz. b) aynı anda başka nelerin çalıştığına bakmadınız. Bir SQL İzleme aracınız ya da gerekli performans verilerini toplayan kendi özel veri toplama komut dosyalarınız yoksa, yeniden başlatma performans istatistiklerini silecektir.
2. Yeniden başlatma çok yavaş. Üretim zamanlarında, yeniden başlatmanın sorunu “düzelteceğini” biliyorsanız, 30 dakika boyunca sorun gidermeye çalışmak ve ardından yine de yeniden başlatmak zorunda kalmak yerine yeniden başlatmak ve birkaç dakika kesinti yaşamak daha iyi olabilir. Yeniden başlatmak daha iyi olabilir. Her zaman değil. Ama bazen. Ardından, bu sorun tekrar ortaya çıktığında bir dahaki sefere ne yapacağınızı hazırlamak için biraz zaman harcayın. Çalıştıracağınız bazı komut dosyaları hazırlayın. Neler olup bittiğinin ayrıntılarını yakalamak için bazı TSQL yazın. Hatta belki bunların bir kısmını otomatikleştirin.
3. Neyin yavaş olduğunu daraltmamak. Tam olarak neyin yavaş olduğu hakkında ne kadar çok ayrıntıya sahip olursanız, sorun giderme o kadar kolay olur.
4. Yavaş çalışan bir sorgu veya stored procedure çalıştırıldığında kullanılan parametreleri tam olarak bilmemek.
5. Bir sonraki yavaşlık için hazır olmamak. Yavaşlık sizi şaşırtmamalıdır. Bu durum gerçekleşmeden önce atmanız gereken adımları bilmeniz gerekir. Plan ve komut dosyalarını hazır bulundurun.

SQL Ayarlama için Gereksinimler

1. Sorunla ilgili görüntüleme yetkiniz yok. Örneğin, sunucuda sistem yöneticisi değilsiniz. Bu, neye bakabileceğinizi sınırlayacaktır.
2. Bazı araçları çalıştıramazsınız. Yardımcı olabilecek tüm küçük ve belirsiz araçların farkında değilsiniz.
3. Eski SQL Server sürümü. SQL Server sürümü ne kadar eski olursa, performansı belirlemek ve ayarlamak için o kadar az seçeneğiniz olur.
4. Win OS ne kadar eskiyse, bu da o kadar zor olacaktır.
5. Her katmandan sorumlu kişilerle konuşamamak (AWS/Azure bulut yöneticileri, DevOps, Windows sistem yöneticileri, depolama yöneticileri, VMWARE yöneticileri, ağ yöneticileri, vb.)
6. Kullanıma hazır herhangi bir araç veya komut dosyasına sahip olmamak. Sorunu gördüğünüzde Google’da ararsınız.
7. Çok uzun sürüyor. Her sorun çözülebilir – eninde sonunda. Asıl soru, ayarlama yapmak için zamanınız var mı, yoksa sadece performans ayarlama yapan birini mi çağırmak daha iyi?
8. Değişiklik yapmanıza izin verilmiyor.
9. Test edecek yer yok.
10. Performans ayarını sıfır deneyimle birinin sorunu haline getirmek.

Bir sonraki SQL yavaşlığı için bir PRO gibi hazırlanın

1. Bir dahaki sefere yavaşlık olduğunda yapacağınız kesin adımları hazırlayın. Kontrol edeceğiniz DMV’yi araştırın. Böyle bir durumda ne yapmanız gerektiği konusunda kendinizi eğitmek için şimdiden zaman ayırın. Uyarı: bu öğrenmesi kolay bir şey değildir.
2. Birini görevlendirin. Bir DBA, veritabanı geliştiricisi veya programcı getirin. Sadece bunun zaman alacağını bilin. Özellikle de bu kişi her gün performans sorunlarıyla ilgilenmiyorsa.
3. Neyin normal olduğunu bilin. Temel değeriniz nedir? Bu sotred procedure genellikle 4 saniyede mi yoksa 0.4 saniyede mi çalışıyor?
4. Bir profesyonel kiralayın. Aryasoft Bilgi Teknolojileri gibi bir şirketle çalışın. Yardım etmeyi çok isteriz! Her gün mükemmel yakın ayarlamalar yapıyoruz ve bunu on yılı aşkın süredir yapıyoruz. MUHTEŞEM referanslarımıza ve örnek olay incelemelerimize bir göz atın.