SQL Server (Microsoft SQL Server) veritabanı performansını artırmanın en etkili yolu, donanım eklemeden önce sistemin nerede beklediğini ölçmektir. “Sistem yavaşladı” şikâyeti geldiğinde ilk refleks genellikle sunucuya RAM veya CPU eklemek olur. Bu bazen işe yarar, çoğu zaman da problemi birkaç ay erteler. Kalıcı çözüm, yavaşlığın nerede olduğunu ölçmekle başlar.

Aşağıda, sahada en sık karşılaştığımız ve en yüksek getiriyi sağlayan on başlığı sıraladık. Bu adımların çoğu, sunucuya tek bir kuruş harcamadan, sadece doğru ölçüm ve yapılandırmayla uygulanabilir.

10 Yöntemin Özet Tablosu

#	Yöntem	Ne Zaman Öncelikli	Maliyet
1	Bekleme istatistikleri (wait stats)	Her zaman — teşhisin ilk adımı	Ücretsiz
2	En pahalı sorguları bulma	Belirli saatlerde yavaşlama varsa	Ücretsiz
3	İndeks düzenleme	Tablo taraması / yavaş sorgular çoksa	Ücretsiz
4	İstatistik güncelleme	Yanlış sorgu planı seçiliyorsa	Ücretsiz
5	İndeks bakımını otomatikleştirme	Parçalanma oranı yüksekse	Ücretsiz (Ola Hallengren)
6	tempdb yapılandırması	Yoğun geçici tablo/sıralama kullanımı varsa	Ücretsiz
7	Bellek (max server memory) sınırlama	Aynı sunucuda başka servis varsa	Ücretsiz
8	Disk ayrımı (veri/log/yedek)	Disk G/Ç bekleme süreleri yüksekse	Donanım gerektirebilir
9	Raporlama yükünü ayırma	OLTP + raporlama aynı sunucudaysa	Orta (ek sunucu/replika)
10	Sorgu/uygulama tarafı düzeltmeleri	Kod seviyesinde tekrar eden hatalar varsa	Geliştirme emeği

1. Önce ölçün: bekleme istatistikleri (wait stats)

SQL Server, ne beklediğini size söyler. Sunucu diskte mi, kilitte mi, CPU’da mı, bellekte mi bekliyor — bunu bilmeden yapılan her müdahale tahmindir.

SELECT TOP 20
    wait_type,
    wait_time_ms / 1000.0 AS wait_time_sn,
    waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','SLEEP_TASK','BROKER_TASK_STOP',
                        'XE_TIMER_EVENT','SQLTRACE_INCREMENTAL_FLUSH_SLEEP')
ORDER BY wait_time_ms DESC;

PAGEIOLATCH_* yoğunsa disk veya eksik indeks, LCK_M_* yoğunsa kilitlenme, CXPACKET/CXCONSUMER yoğunsa paralellik ayarları, RESOURCE_SEMAPHORE görünüyorsa bellek baskısı sinyali verir. Bu DMV’nin tüm alanlarının resmi tanımı için Microsoft’un sys.dm_os_wait_stats dokümantasyonuna¹ başvurabilirsiniz.

2. En pahalı sorguları bulun

Yükün büyük kısmını genellikle birkaç sorgu üretir. Query Store (SQL Server 2016 ve üzeri) bunu görmenin en pratik yoludur; alternatif olarak sys.dm_exec_query_stats üzerinden toplam CPU ve okuma bazında sıralama yapılabilir. Tek bir rapor sorgusunu düzeltmek, bazen tüm sunucuyu rahatlatır.

3. Eksik ve gereksiz indeksleri düzenleyin

Eksik indeks tablo taramalarına, fazla indeks ise her INSERT/UPDATE işleminde ek maliyete yol açar. sys.dm_db_missing_index_details önerilerini körü körüne uygulamayın — bunlar öneri değil, ipucudur. Kullanılmayan indeksleri de sys.dm_db_index_usage_stats ile tespit edip temizleyin.

4. İstatistikleri güncel tutun

Sorgu iyileştirici (query optimizer) kararlarını istatistiklere göre verir. Bayat istatistik, doğru indeks varken bile yanlış plan seçilmesine neden olur. Büyük tablolarda otomatik güncelleme eşiği geç tetiklenebildiği için, planlı istatistik güncellemesi şarttır.

5. İndeks bakımını otomatikleştirin

Parçalanma (fragmentation) oranına göre yeniden düzenleme (reorganize) veya yeniden oluşturma (rebuild) işlemleri, bakım penceresinde otomatik çalışmalıdır. Ola Hallengren bakım çözümü bu iş için yaygın kabul görmüş, ücretsiz ve güvenilir bir standarttır.

6. tempdb’yi doğru yapılandırın

tempdb, sıralama, geçici tablolar ve sürüm deposu için ortak kaynaktır ve darboğaz olmaya çok müsaittir. Çekirdek sayısına uygun sayıda (genelde 4–8) eşit boyutlu veri dosyası, hızlı bir disk ve makul bir başlangıç boyutu ciddi fark yaratır.

7. Bellek ayarlarını elle sınırlayın

max server memory varsayılan değerinde bırakılırsa SQL Server, işletim sistemini sıkıştırabilir. Sunucudaki diğer yüklere yer bırakacak şekilde üst sınır belirlenmelidir. Aynı sunucuda ERP uygulama servisi de çalışıyorsa bu ayar daha da kritiktir.

8. Diskleri ayırın

Veri dosyaları, log dosyaları ve yedekler mümkün olduğunca farklı disk/volume üzerinde olmalıdır. Log yazımı sıralı ve gecikmeye duyarlıdır; veri okumasıyla aynı diski paylaşması performansı doğrudan etkiler. Günümüzde en yüksek getirili tek donanım yatırımı, hâlâ NVMe/SSD’ye geçiştir.

9. Raporlama yükünü ayırın

Ağır analitik raporların işlem (OLTP) veritabanı üzerinde çalışması, gün içinde herkesi etkiler. Read-only replika, gece beslenen bir raporlama veritabanı veya ayrı bir BI katmanı bu yükü ana sistemden çıkarır. ÇAP Teknoloji’nin BI/veri analitiği danışmanlığında tam olarak bu ayrım esas alınır — raporlama, üretim veritabanının performansını hiçbir zaman riske atmamalıdır.

10. Sorgu ve uygulama tarafını gözden geçirin

SELECT * yerine yalnızca gerekli kolonlar
WHERE koşulunda kolon üzerinde fonksiyon kullanmaktan kaçınma (indeks devre dışı kalır)
Parametre veri tipi uyumsuzluğunun yol açtığı örtük dönüşümler (implicit conversion)
Satır satır işlem yapan döngüler yerine küme tabanlı (set-based) yazım
Uzun süre açık kalan işlemler (transaction)

Sıkça Sorulan Sorular

SQL Server performans sorununu donanım eklemeden çözmek mümkün mü?

Çoğu zaman evet. Sahada karşılaşılan yavaşlıkların büyük kısmı, eksik/gereksiz indeks, bayat istatistik veya yanlış tempdb yapılandırması gibi donanımla ilgisi olmayan nedenlerden kaynaklanır. Donanım yatırımı, ancak ölçüm sonrası darboğazın gerçekten kaynak yetersizliği olduğu doğrulandığında anlamlıdır.

Wait stats analizine ne sıklıkla bakılmalı?

Kritik sistemlerde haftalık bir rutin olarak izlenmesi idealdir. Ayrıca sunucu yeniden başlatıldığında sayaçlar sıfırlandığı için, bir performans sorunu sonrası yapılan analizde “ne zamandan beri” biriktiğine dikkat edilmelidir.

İndeks eklemek her zaman performansı artırır mı?

Hayır. Her ek indeks, okuma performansını iyileştirirken INSERT/UPDATE/DELETE işlemlerine ek maliyet bindirir. Bu yüzden sys.dm_db_missing_index_details önerileri körü körüne değil, gerçek sorgu yüküyle birlikte değerlendirilmelidir.

Küçük bir işletme için bu adımların hepsi gerekli mi?

Hayır, önceliklendirme gerekir. Yukarıdaki özet tablodaki ilk 4 madde (ölçüm, sorgu analizi, indeks, istatistik) hemen her ölçekte en yüksek getiriyi sağlar; disk ayrımı veya ayrı raporlama katmanı gibi adımlar ise veri hacmi ve kullanıcı sayısı arttıkça öncelik kazanır.

Sonuç

Performans çalışması bir kerelik iş değil, döngüdür: ölç → en büyük darboğazı düzelt → tekrar ölç. Tek seferde her şeyi değiştirmek, neyin işe yaradığını anlamanızı da imkânsız hale getirir. Wait stats ve sorgu analizini SQL veritabanınızın sessiz risklerini ele aldığımız yazımızda daha geniş kapsamda inceleyebilirsiniz.

ÇAP Teknoloji olarak SQL Server danışmanlığı hizmetimizde ortamlarınızda bekleme istatistiği ve sorgu bazlı analiz yapıp, önceliklendirilmiş bir iyileştirme planı çıkarıyoruz. Sunucu yatırımı yapmadan önce mevcut sistemin ne kadar hızlanabileceğini görmek isterseniz ücretsiz teklif talep edebilirsiniz.

Kaynaklar:
1. Microsoft Learn, sys.dm_os_wait_stats (Transact-SQL) – SQL Server. learn.microsoft.com

SQL Veritabanı Performansını Artırmanın 10 Yolu