Özet: Bekleme istatistikleri, Query Store, indeksler, bellek ve MAXDOP: yavaşlayan bir SQL Server'da sorunu bulmak için sahada kullandığımız kontrol sırası.

"Veritabanı yavaş" şikâyeti çoğu zaman tek bir sorgudan değil, birkaç küçük sorunun üst üste binmesinden doğar. Sunucuya daha fazla RAM ya da çekirdek eklemeden önce nereye bakacağınızı bilmek hem zaman hem bütçe kazandırır.

Aşağıdaki sıra, Microsoft SQL Server ortamlarında sahada kullandığımız kontrol listesinin özeti. Adımların hepsi yalnızca okuma yetkisiyle yapılabilir.

1. Önce bekleme istatistiklerine bakın

SQL Server her sorgunun neyi beklediğini kaydeder. sys.dm_os_wait_stats görünümü sunucunun zamanının nereye gittiğini gösterir: disk (PAGEIOLATCH), kilit (LCK_M_*), paralellik (CXPACKET / CXCONSUMER) ya da bellek (RESOURCE_SEMAPHORE). Bekleme profili, sonraki adımda hangi alana odaklanacağınızı belirler.

2. Query Store ile plan regresyonlarını bulun

Dün hızlı çalışan bir sorgu bugün yavaşsa, çoğu zaman sorgu planı değişmiştir. SQL Server 2016 ve sonrasında Query Store açıksa aynı sorgunun farklı planlarını ve süre değişkenliğini yan yana görebilirsiniz. Zorlanmış (forced) bir planın sessizce başarısız olması da burada ortaya çıkar.

3. Sorgu metnindeki anti-pattern'leri ayıklayın

Bazı yazım alışkanlıkları indeks kullanımını engeller:

  • Baştan joker LIKE: LIKE '%abc' indeks aramasını taramaya çevirir.
  • WHERE'de kolona fonksiyon: WHERE YEAR(Tarih) = 2026 yerine tarih aralığı yazın.
  • NOT IN ve NULL: beklenmedik sonuç ve kötü plan üretebilir; NOT EXISTS daha güvenlidir.
  • Skaler UDF ve cursor: satır satır çalışarak küme tabanlı işlemenin önüne geçer.
  • SELECT *: gereksiz kolon okur, kapsayan indeksleri işe yaramaz hale getirir.

4. İndeks sağlığını kontrol edin

Eksik indeks önerileri, hiç kullanılmayan ama her yazmada güncellenen indeksler ve aynı kolonları tekrar eden indeksler birlikte değerlendirilmelidir. Her öneriyi körü körüne eklemek yazma performansını düşürür.

5. Bellek ve paralellik ayarlarını gözden geçirin

Kurulumda varsayılan bırakılan iki ayar sık sorun çıkarır. Max Server Memory sınırsız bırakılırsa işletim sistemi bellek sıkıntısına düşer. MAXDOP ve cost threshold for parallelism varsayılanda kalırsa küçük sorgular gereksiz yere paralel çalışır. Doğru değerler sunucunun çekirdek sayısına, NUMA düzenine ve toplam RAM'ine göre hesaplanır.

6. Bakım işlerinin gerçekten çalıştığını doğrulayın

İstatistik güncellemesi, indeks bakımı, DBCC CHECKDB ve yedek işlerinin son çalışma sonuçlarına bakın. Zamanlanmış ama aylardır hata veren bir bakım işi en sık gözden kaçan sorunlardan biridir.

7. Güvenlik yapılandırmasını aynı turda okuyun

Performans incelemesi yapılandırmaya bakmak için iyi bir fırsattır: sysadmin yetkisi kimlerde, SQL Audit tanımlı ve çalışıyor mu, xp_cmdshell gibi riskli özellikler açık mı, parola politikası kapalı login var mı.

Pratik öneri

Değişiklikleri tek tek yapın ve her adımdan sonra ölçün. Aynı anda üç ayarı değiştirirseniz hangisinin işe yaradığını bilemezsiniz. Düzeltme betiklerini önce test ortamında çalıştırın.

Bu kontrolleri düzenli hale getirmek

Cardinal, yukarıdaki kontrolleri en düşük yetkili bir SQL hesabıyla (VIEW SERVER STATE, VIEW DATABASE STATE, VIEW ANY DEFINITION) düzenli olarak yapar ve sonuçları 0–100 arası bir SQL Health Score'da toplar. Query Advisor 14 anti-pattern için before → after önerisi üretir; gerçek bir müşteride ölçülen örnekte bir sorgu 8,2 saniyeden 1,7 saniyeye indi. Düzeltme betikleri sunucunuza özel hesaplanır ama asla otomatik çalıştırılmaz.

SQL Server'ınızın sağlık skorunu öğrenin

İlk sağlık taramasını birlikte yapalım; bulguları ve önceliklendirilmiş önerileri rapor olarak alın.

Sağlık taraması talep et