SQL Server Wait Stats Analizi: Pratik Tanı İş Akışı

Wait istatistikleri, SQL Server oturumlarının çalışmak yerine neyi beklediğini gösterir. sys.dm_os_wait_stats görünümünden birkaç dakika arayla iki anlık görüntü alın, farkını hesaplayın, boşta bekleyen wait’leri eleyin ve en büyük wait türünü okuyun: LCK_M_* blocking’e, PAGEIOLATCH_* depolamadan okumaya, WRITELOG log yazımına, SOS_SCHEDULER_YIELD CPU’ya işaret eder. Sonra arkasındaki sorgularla doğrulayın.

Bir wait türü teşhis değil, belirtidir. Bu rehber tekrarlanabilir bir iş akışı verir: ölç, daralt, sorguları bul, tek şeyi değiştir, tekrar ölç. Belirti-kanıt-çözüm matrisi, karar ağacı ve kendi instance’ınıza uyarlayabileceğiniz salt okunur T-SQL içerir.

Son doğrulama: 19 Ekim 2026. Microsoft Learn dokümantasyonu (wait istatistikleri, mevcut istekler ve bekleyen görevler, Query Store wait istatistikleri) ile karşılaştırıldı. T-SQL örnekleri SQL Server 2025 (build 17.0.4055.5) üzerinde test edilmiştir.

Wait İstatistikleri Size Ne Söyler (ve Ne Söylemez)

sys.dm_os_wait_stats, çalışan thread’lerin karşılaştığı tüm wait’leri instance genelinde toplayarak döndürür. Tamamlanmış wait’lerin süresini gösterir, o an süren wait’leri göstermez. Değerler son yeniden başlatmadan veya sayaç sıfırlamadan beri birikimlidir ve yeniden başlatmalarda korunmaz.

En önemli iki kolon vardır. wait_time_ms, signal_wait_time_ms değerini de içerir; bu, thread’in sinyal alması ile CPU’ya geri dönmesi arasındaki süredir. Dolayısıyla wait_time_ms - signal_wait_time_ms kaynağın kendisini beklemede geçen süredir; yüksek bir signal payı ise adı geçen kaynaktan çok CPU zamanlama baskısına işaret eder.

Wait’ler hangi sorgunun sorumlu olduğunu da söylemez; birikimli toplam gece işleriyle mesai saatlerindeki yükü karıştırır. Bu yüzden aşağıdaki iş akışı kısa bir fark (delta) örneği, ardından istek ve sorgu bazlı görünümler kullanır.

Beş Adımlı Tanı İş Akışı

Aşağıdaki tüm betikler yalnızca sistem görünümlerinden okur; tek istisna, 2. betiğin tempdb’de oturum kapsamlı geçici bir tablo oluşturmasıdır. SQL Server’da VIEW SERVER STATE yetkisi gerekir; Azure SQL Database Premium katmanlarında wait görünümü için dokümante edilen gereksinim VIEW DATABASE STATE yetkisidir.

Adım 1: Son yeniden başlatmadan beri ilk resmi alın

Boşta bekleme dışlama listesi pragmatik bir başlangıç noktasıdır, Microsoft’un resmi listesi değildir. Microsoft’un Query Store wait kategorileri, SLEEP_%, LAZYWRITER_SLEEP, XE_DISPATCHER_WAIT ve REQUEST_FOR_DEADLOCK_SEARCH gibi birkaç adı Idle olarak sınıflandırır. Listeye güvenmeden önce kendi sürümünüz için gözden geçirin.

-- Salt okunur. Son yeniden başlatma veya sıfırlamadan beri birikimli wait değerleri.
-- Dışlama listesi başlangıç noktasıdır, resmi bir liste değildir.
SELECT TOP (15)
       ws.wait_type,
       ws.waiting_tasks_count,
       ws.wait_time_ms,
       ws.wait_time_ms - ws.signal_wait_time_ms AS resource_wait_ms,
       ws.signal_wait_time_ms,
       CAST(1.0 * ws.wait_time_ms / ws.waiting_tasks_count AS decimal(18, 2)) AS avg_wait_ms,
       CAST(100.0 * ws.wait_time_ms
            / NULLIF(SUM(ws.wait_time_ms) OVER (), 0) AS decimal(5, 2)) AS pct_of_listed_wait_time
FROM sys.dm_os_wait_stats AS ws
WHERE ws.waiting_tasks_count > 0
  AND ws.wait_type NOT LIKE N'SLEEP[_]%'
  AND ws.wait_type NOT IN (
        N'LAZYWRITER_SLEEP', N'SLEEP_TASK', N'SQLTRACE_BUFFER_FLUSH',
        N'XE_TIMER_EVENT', N'XE_DISPATCHER_WAIT', N'XE_DISPATCHER_JOIN',
        N'XE_LIVE_TARGET_TVF', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'CHECKPOINT_QUEUE', N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
        N'BROKER_RECEIVE_WAITFOR', N'DIRTY_PAGE_POLL', N'LOGMGR_QUEUE',
        N'SP_SERVER_DIAGNOSTICS_SLEEP', N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
        N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'ONDEMAND_TASK_QUEUE',
        N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', N'WAITFOR')
ORDER BY ws.wait_time_ms DESC;

Adım 2: Sorun penceresinde delta ölçün

Yavaşlık sürerken çalıştırın. Sayaçları kaydeder, bir dakika bekler ve yalnızca aradaki sürede biriken wait’leri gösterir. Örnekleme sırasında sayaçlar sıfırlanır veya instance yeniden başlarsa farkı negatif olan satırlar elenir; örneği tekrarlayın.

-- Yalnızca oturum kapsamlı geçici tablo oluşturur; sistem görünümlerini okur.
IF OBJECT_ID(N'tempdb..#w1') IS NOT NULL DROP TABLE #w1;

SELECT wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
INTO #w1
FROM sys.dm_os_wait_stats;

WAITFOR DELAY '00:01:00';   -- örnek süresi: aralıklı sorunlarda uzatın

SELECT TOP (15)
       w2.wait_type,
       w2.waiting_tasks_count - w1.waiting_tasks_count AS waits_in_sample,
       w2.wait_time_ms - w1.wait_time_ms AS wait_ms_in_sample,
       w2.signal_wait_time_ms - w1.signal_wait_time_ms AS signal_ms_in_sample
FROM sys.dm_os_wait_stats AS w2
JOIN #w1 AS w1 ON w1.wait_type = w2.wait_type
WHERE w2.wait_time_ms - w1.wait_time_ms > 0
  AND w2.wait_type NOT LIKE N'SLEEP[_]%'
  AND w2.wait_type NOT IN (
        N'LAZYWRITER_SLEEP', N'SLEEP_TASK', N'SQLTRACE_BUFFER_FLUSH',
        N'XE_TIMER_EVENT', N'XE_DISPATCHER_WAIT', N'XE_DISPATCHER_JOIN',
        N'XE_LIVE_TARGET_TVF', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'CHECKPOINT_QUEUE', N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
        N'BROKER_RECEIVE_WAITFOR', N'DIRTY_PAGE_POLL', N'LOGMGR_QUEUE',
        N'SP_SERVER_DIAGNOSTICS_SLEEP', N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
        N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'ONDEMAND_TASK_QUEUE',
        N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', N'WAITFOR')
ORDER BY wait_ms_in_sample DESC;

DROP TABLE #w1;

Adım 3: Şu anda kimin beklediğini görün

sys.dm_exec_requests o anda çalışan istekleri gösterir; wait_type ve wait_time yalnızca istek beklerken doludur, last_wait_type ise önceki wait’i gösterir. VIEW SERVER STATE yetkisi yoksa yalnızca kendi oturumunuzu görürsünüz. sys.dm_os_waiting_tasks, paralel worker thread’ler dahil, bekleyen her görev için bir satır ekler. Betik ayrıca sistem oturumlarını atlamak için sys.dm_exec_sessions, ifade metnini okumak için sys.dm_exec_sql_text kullanır.

-- Salt okunur. Şu anda çalışan veya bekleyen istekler.
SELECT r.session_id,
       r.status,
       r.command,
       DB_NAME(r.database_id) AS database_name,
       r.wait_type,
       r.wait_time AS wait_ms,
       r.last_wait_type,
       r.wait_resource,
       r.blocking_session_id,
       r.cpu_time AS cpu_ms,
       r.total_elapsed_time AS elapsed_ms,
       r.logical_reads,
       SUBSTRING(t.text,
                 (r.statement_start_offset / 2) + 1,
                 ((CASE r.statement_end_offset
                        WHEN -1 THEN DATALENGTH(t.text)
                        ELSE r.statement_end_offset
                   END - r.statement_start_offset) / 2) + 1) AS running_statement
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE s.is_user_process = 1
  AND r.session_id <> @@SPID
ORDER BY r.total_elapsed_time DESC;

-- Salt okunur. Bekleyen her görev için bir satır (paralel sorgular birden fazla satır gösterir).
SELECT wt.session_id,
       wt.exec_context_id,
       wt.wait_type,
       wt.wait_duration_ms,
       wt.blocking_session_id,
       wt.resource_description
FROM sys.dm_os_waiting_tasks AS wt
JOIN sys.dm_exec_sessions AS s ON s.session_id = wt.session_id
WHERE s.is_user_process = 1
ORDER BY wt.wait_duration_ms DESC;

Adım 4: Wait’in arkasındaki sorguları bulun (geçmiş)

Query Store açıksa (SQL Server 2017 ve sonrası ile Azure SQL Database), sys.query_store_wait_stats wait’leri ham wait türü yerine plan, aralık ve wait kategorisi bazında toplar. Microsoft’un eşlemesi örneğin LCK_M_% türlerini Lock, PAGEIOLATCH_% türlerini Buffer IO ve WRITELOG türünü Tran Log IO kategorisine koyar. Query Store raporları aynı veri için bir Query Wait Statistics görünümü içerir. Etkinleştirme ve boyutlandırma için Query Store rehberimize bakın.

-- Salt okunur. Son 24 saatte sorgu bazında en yüksek boşta olmayan wait kategorileri.
-- Query Store açık olmalıdır; total_query_wait_time_ms milisaniyedir.
SELECT TOP (20)
       ws.wait_category_desc,
       q.query_id,
       p.plan_id,
       SUM(ws.total_query_wait_time_ms) AS total_wait_ms,
       LEFT(qt.query_sql_text, 200) AS query_text_start
FROM sys.query_store_wait_stats AS ws
JOIN sys.query_store_runtime_stats_interval AS i
     ON i.runtime_stats_interval_id = ws.runtime_stats_interval_id
JOIN sys.query_store_plan AS p ON p.plan_id = ws.plan_id
JOIN sys.query_store_query AS q ON q.query_id = p.query_id
JOIN sys.query_store_query_text AS qt ON qt.query_text_id = q.query_text_id
WHERE i.start_time >= DATEADD(HOUR, -24, SYSDATETIMEOFFSET())
  AND ws.wait_category_desc <> N'Idle'
GROUP BY ws.wait_category_desc, q.query_id, p.plan_id, LEFT(qt.query_sql_text, 200)
ORDER BY total_wait_ms DESC;

Zaman filtresi için kullanılan aralık görünümünün start_time kolonu datetimeoffset türündedir. Query Store olmadan da CPU odaklı bir geçmiş sys.dm_exec_query_stats ile elde edilebilir; DMV’lerle yavaş sorguları bulma rehberimize bakın.

Adım 5: Tek şeyi değiştirin, sonra tekrar ölçün

Kanıtın işaret ettiği nedeni aşağıdaki matrisi kullanarak düzeltin, ardından benzer bir pencerede 2. adımdaki örneği tekrarlayın. En büyük wait listede sadece aşağı kayıyorsa bu başarısız bir düzeltme değil, normal ilerlemedir. Sonraki kişi neyin değiştiğini görebilsin diye önce ve sonra değerlerini yazın.

Belirti → Kanıt → Çözüm Matrisi

İkinci kolon, Microsoft’un her wait türü için verdiği açıklamalara dayanır. Çözüm yönü yargının başladığı yerdir; bunu talimat değil, bir sonraki inceleme adımı olarak değerlendirin.

Karar Ağacı: En Büyük Wait’ten Sonraki Adıma

Soruları sırayla izleyin ve eşleşen ilk dalda durun.

1. Yavaşlık şu anda yaşanıyor mu? Evet: 3. adımı çalıştırın ve wait_type, blocking_session_id ve ifadeyi okuyun. Hayır veya aralıklı: bir sonraki olayda 2. adımdaki delta’yı veya 4. adımdaki Query Store geçmişini kullanın.
2. blocking_session_id dolu mu? Evet: zinciri baştaki bloklayıcıya kadar izleyin ve o oturumun transaction’ını veya sorgusunu düzeltin. Birikimli en büyük wait başka olsa bile bu bir kilitleme sorunudur.
3. En büyük boşta olmayan wait çoğunlukla kaynak wait’i mi, signal wait mi? resource_wait_ms ile signal_ms_in_sample veya signal_wait_time_ms değerlerini karşılaştırın.
   • Signal payı yüksek: CPU zamanlama baskısı. En çok CPU kullanan sorgularla başlayın.
   • LCK_M_*: bloklama. PAGEIOLATCH_*: okuma I/O’su ve taramalar. WRITELOG: commit hızı ve log depolama. RESOURCE_SEMAPHORE: bellek istekleri. ASYNC_NETWORK_IO: yavaş istemci.
   • Yalnızca CXPACKET/CXCONSUMER: MAXDOP’a dokunmadan önce matristeki paralellik satırını okuyun.
4. Wait’i üreten sorguları adlandırabiliyor musunuz? Hayır: 4. adımı (Query Store) veya DMV tabanlı yavaş sorgu aramasını kullanın. Evet: bu sorguları iyileştirin, sonra 2. adımı tekrarlayın.
5. Aynı sorgu yalnızca bazı parametre değerleri için mi yavaş? Bu bir kaynak değil, plan sorunudur. Parameter sniffing rehberimize bakın.

Resmi Davranış, Aryasoft Saha Notları ve Önerimiz

Sık Yapılan Hatalar

• Birikimli en büyük wait’e göre ayar yapmak. Dün geceki işe ait olabilir.
• CXPACKET veya THREADPOOL nedeniyle MAXDOP veya max worker thread artırmak. Microsoft’un ifadesi CXPACKET için önce sorgunun iyileştirilmesine işaret eder ve THREADPOOL için uzun süren batch’leri nedenlerden biri olarak gösterir.
• Signal wait’leri yok saymak. Yüksek signal payı, thread’lerin hazır olduğunu ama CPU’ya dönmeyi beklediğini gösterir.
• Aynı anda birden fazla şeyi değiştirmek. Neyin işe yaradığını bilemezsiniz.
• ASYNC_NETWORK_IO wait’ini ağ ekibi sorunu saymak. Microsoft, istemcinin sunucudan gelen veriyi işleyip işlemediğinin doğrulanmasını söyler.
• Bunlara benzer daha fazla örüntü SQL Server performans ayarı hataları yazımızda.

Sık Sorulan Sorular

Aryasoft Wait Tabanlı Sorun Gidermede Nasıl Çalışır?

Bir performans değerlendirmesinde işin bildirdiği belirtiden başlar, o pencerede wait delta’sı ve sorgu bazlı kanıt toplar, her seferinde tek şeyi değiştirir ve önce/sonra değerlerini belgeleriz.

Sahadan bir örnek: Büyük bir üretim firmasında ay sonu raporu tüm sistemi kilitledi. Blocking zinciri head blocker olarak bu rapora çıkıyordu; ekip o session’ı sonlandırdı ve sistem 12 dakikada normale döndü. Ardından rapor optimize edildi ve çalışma süresi 4 saatten 19 dakikaya indi. Daha geniş kapsam için SQL Server danışmanlığı sayfamıza bakın.

Kaynaklar

Bu rehberdeki teknik iddialar 19 Ekim 2026 tarihinde aşağıdaki Microsoft dokümantasyonuna karşı kontrol edildi. Gösterilen tarih dokümantasyon kaynak dosyasının “ms.date” değeridir, sayfanın değişmediğinin garantisi değildir. Üretimde değişiklik yapmadan önce sürüme özgü ayrıntıları yeniden kontrol edin.

1. sys.dm_os_wait_stats (Transact-SQL) (ms.date: 05/16/2019)
2. sys.dm_os_waiting_tasks (Transact-SQL) (ms.date: 03/13/2017)
3. sys.dm_exec_requests (Transact-SQL) (ms.date: 06/03/2019)
4. sys.dm_exec_session_wait_stats (Transact-SQL) (ms.date: 04/24/2018)
5. sys.query_store_wait_stats (Transact-SQL) (ms.date: 04/21/2017)
6. Best practices for monitoring workloads with Query Store (ms.date: 01/26/2026)
7. sys.dm_exec_sessions (Transact-SQL) (ms.date: 06/03/2019)
8. sys.dm_exec_sql_text (Transact-SQL) (ms.date: 10/20/2017)
9. sys.query_store_runtime_stats_interval (Transact-SQL) (ms.date: 01/23/2019)
10. sys.dm_exec_query_stats (Transact-SQL) (ms.date: 05/30/2019)