SQL Server Yavaşladıysa İlk 5 Dakikada Bakılması Gereken Yerler
SQL Server Yavaşladıysa İlk 5 Dakikada Bakılması Gereken Yerler
SQL Server yavaşladığında çoğu ortamda refleksler aynıdır: CPU’ya bakılır, RAM yetmiyor mu denir,
“restart atalım mı?” sorusu gelir. Oysa üretim ortamlarında performans problemlerinin büyük kısmı
bu reflekslerle yanlış teşhis edilir ve sorun kalıcı çözülmez.
Bu yazıda, canlı bir SQL Server ortamı yavaşladığında ilk 5 dakikada gerçekten nereye bakılması gerektiğini
sahada kullanılan net ve sıralı bir yaklaşımla anlatıyorum.
1️⃣ Gerçekten CPU mu Sorunlu, Yoksa CPU Bekleniyor mu?
Görev Yöneticisi veya monitoring ekranında CPU’nun %80–90 görünmesi her zaman CPU darboğazı olduğu anlamına gelmez. Asıl soru şudur: CPU çalışıyor mu, yoksa işlemler sırada mı bekliyor? Bunun en pratik yolu scheduler (runnable queue) kontrolüdür.
SELECT scheduler_id, runnable_tasks_count, load_factor FROM sys.dm_os_schedulers WHERE status = 'VISIBLE ONLINE';
- runnable_tasks_count sürekli 0–1 ise: CPU darboğazı yoktur.
- Bu değer sürekli yüksekse: CPU talepleri karşılayamıyordur (CPU queue doludur).
- CPU %90 görünse bile runnable queue boşsa: sorun CPU değildir.
2️⃣ SQL Server Aslında Neyi Bekliyor?
SQL Server “yavaş” olduğunda çoğu zaman çalışmıyordur; bir şeyin olmasını bekliyordur. Bu nedenle kök sebep analizi için ilk bakılacak yerlerden biri wait stats olur.
SELECT TOP (10) wait_type, wait_time_ms / 1000.0 AS wait_seconds FROM sys.dm_os_wait_stats WHERE wait_type NOT LIKE 'SLEEP%' ORDER BY wait_time_ms DESC;
- PAGEIOLATCH_* → Disk IO / storage gecikmesi veya yanlış indeks / ağır okuma
- LCK_M_* → Kilitlenme / blokaj
- CXPACKET / CXCONSUMER → Paralellik ayarı / kötü plan / dengesiz iş dağılımı
- WRITELOG → Log diski yavaşlığı veya yoğun transaction yükü
3️⃣ Sistemi Gerçekte Hangi Sorgu Yavaşlatıyor?
“SQL Server yavaş” vakalarının büyük bölümünde sorun sistemin tamamı değil; tek veya birkaç pahalı sorgudur. Bu yüzden hızlıca “en pahalı sorgu” listesini çıkar.
SELECT TOP (5) qs.execution_count, qs.total_worker_time / NULLIF(qs.execution_count,0) AS avg_cpu_time, qs.total_elapsed_time / NULLIF(qs.execution_count,0) AS avg_elapsed_time, SUBSTRING(st.text, 1, 4000) AS query_text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st ORDER BY avg_cpu_time DESC;
- Az çalışan ama her çalıştığında çok pahalı olan sorgular
- Çok sık çalışan ve her seferinde CPU tüketen sorgular
4️⃣ Kilitlenme (Blocking) Var mı?
Bazı ortamlarda “yavaşlık” aslında CPU/RAM değil; bekleme ve blokaj problemidir. Bir oturum diğerlerini kilitler, zincirleme yavaşlık oluşur.
SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time, DB_NAME(r.database_id) AS database_name, SUBSTRING(t.text, 1, 4000) AS running_query FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t WHERE r.blocking_session_id <> 0;
5️⃣ İlk 5 Dakikadan Sonra Yapılmaması Gerekenler
Bu kontroller yapılmadan aşağıdaki adımlar atılmamalıdır. Çünkü çoğu zaman sorunu geçici maskeleyip kök nedeni saklar:
- CPU artırmak
- RAM eklemek
- Sunucu taşımak
- SQL Server restart etmek
Özet: Sahada Kullanılan Hızlı Kontrol Listesi
| Adım | Soru | Nereye bakılır? |
|---|---|---|
| 1 | CPU gerçekten darboğaz mı? | sys.dm_os_schedulers |
| 2 | SQL Server neyi bekliyor? | sys.dm_os_wait_stats |
| 3 | En pahalı sorgu hangisi? | sys.dm_exec_query_stats |
| 4 | Blocking var mı? | sys.dm_exec_requests |
| 5 | Sorun donanım mı, sorgu mu? | Yukarıdaki 4 bulguyu birleştir |
SQL Server yavaşladığında ilk refleksin “restart” değil, scheduler → wait stats → pahalı sorgu → blocking sırası olmalı. Bu 5 adım doğru teşhisi hızlandırır ve kalıcı çözümün kapısını açar.