Preskočiť na obsah

Čakania

Na čo SQL Server čaká, keď je pomalý – a čo s tým. · 46 typov čakaní

Disk (I/O)

Čakanie na čítanie alebo zápis dátových súborov, záloh a rast súborov.

Disk (I/O) overené 11/2026

PAGEIOLATCH_SH

Dotaz čaká, kým sa dátová stránka načíta z disku do pamäte (buffer pool) na čítanie. Dlhé čakania naznačujú pomalý disk alebo priveľa čítania.

Čo s tým
  • Pozri latenciu dátových súborov (recept I/O latencia) – je disk naozaj pomalý?
  • Nájdi dotazy s najviac fyzickými čítaniami a ich plán: sken veľkej tabuľky namiesto seeku často znamená chýbajúci index.
  • Malý buffer pool (nízke max server memory, tlak na pamäť) núti čítať tie isté stránky z disku znova.
  • V exekučnom pláne: Table Scan, Key Lookup, Plán a čakania
Disk (I/O) overené 11/2026

PAGEIOLATCH_EX

Čakanie na dátovú stránku v I/O operácii v exkluzívnom režime – stránka sa číta z disku, aby ju dotaz mohol zmeniť (alebo sa zapisuje).

Čo s tým
  • Rovnaký postup ako pri PAGEIOLATCH_SH: latencia súborov a dotazy s veľa čítaniami.
  • Veľké UPDATE / DELETE bez vhodného indexu čítajú zbytočne veľa stránok – pozri plán.
  • V exekučnom pláne: Table Scan, Plán a čakania
Disk (I/O) overené 11/2026

IO_COMPLETION

Čakanie na dokončenie I/O, ktoré nie je načítaním dátovej stránky (tie sú PAGEIOLATCH_*).

Čo s tým
  • Porovnaj s latenciou súborov vrátane tempdb a logu.
  • Ak rastie spolu s PAGEIOLATCH_* a WRITELOG, problém je skôr v úložisku ako v jednom dotaze.
Disk (I/O) overené 11/2026

ASYNC_IO_COMPLETION

Úloha čaká na dokončenie asynchrónnych I/O mimo dátových stránok – napr. pri log shippingu, zrkadlení databáz či niektorých bulk operáciách.

Čo s tým
  • Pozri, či čakanie rastie počas záloh a obnovy (recept Priebeh BACKUP / RESTORE).
  • Mimo údržby skontroluj latenciu diskov.
Disk (I/O) overené 11/2026

BACKUPIO

Úloha zálohy čaká na dáta alebo na voľný buffer – vysoké hodnoty počas záloh znamenajú, že čítanie zdroja alebo zápis na cieľ nestíha.

Čo s tým
  • Over rýchlosť cieľa zálohy (sieťové úložisko, deduplikačné zariadenie).
  • Zálohy s COMPRESSION zapisujú menej dát (za cenu CPU); pri veľkých databázach pomôže zálohovať do viacerých súborov.
  • Mimo okna záloh toto čakanie bežne nevidno.
Disk (I/O) overené 11/2026

PREEMPTIVE_OS_WRITEFILEGATHER

SQL Server nuluje nový priestor súboru (rast alebo vytvorenie súboru) a čaká na Windows. Kým nuluje, ostatné dotazy môžu čakať na zámky.

Čo s tým
  • Zapni Instant File Initialization (právo „Perform volume maintenance tasks“ pre servisný účet) – platí len pre dátové súbory.
  • Log sa nuluje (výnimka: od SQL Server 2022 rast logu do 64 MB využije IFI): nastav autogrowth v MB (nie v %) a log zväčši vopred mimo špičky.
  • V error logu hľadaj správy 5144 / 5145 o dlhom raste súboru.

Transakčný log

Zápis do transakčného logu pri commite – latencia disku s logom.

Transakčný log overené 11/2026

WRITELOG

Commit čaká, kým sa záznamy transakcie zapíšu na disk do transakčného logu. Bežné príčiny: pomalý disk s logom alebo veľmi veľa malých commitov.

Čo s tým
  • Pozri latenciu zápisu do súboru logu (recept I/O latencia) – log chce disk s nízkou latenciou.
  • Tisíce malých transakcií v cykle (commit po každom riadku) spoj do dávok.
  • Log nemá byť na tom istom preťaženom disku ako dáta.
  • V exekučnom pláne: INSERT / UPDATE / DELETE v pláne
Transakčný log overené 11/2026

LOGBUFFER

Úloha čaká na voľné miesto v pamäťovom buffri logu – zariadenie s logom nestíha množstvo generovaného logu.

Čo s tým
  • Rovnaký postup ako pri WRITELOG: latencia disku s logom a veľkosť transakcií.
  • Pri hromadných operáciách zváž dávkovanie, aby log nezahltili.

Zámky a latche

Blokovanie medzi transakciami (LCK_M_*) a súperenie o stránky v pamäti (PAGELATCH_*).

Zámky a latche overené 11/2026

LCK_M_S

Dotaz čaká na zdieľaný zámok (S) – typicky čítanie, ktoré blokuje rozpracovaná zmena inej transakcie.

Čo s tým
  • Nájdi, kto blokuje (recept Kto koho blokuje) a koreň reťaze (head blocker).
  • Otvorené transakcie, na ktoré aplikácia zabudla, sú častý vinník (recept Otvorené transakcie).
  • Pre čítajúcu záťaž zváž READ_COMMITTED_SNAPSHOT – čítanie potom nečaká na zápis.
  • V exekučnom pláne: Plán a čakania – prečo to nie je chyba plánu
Zámky a latche overené 11/2026

LCK_M_U

Čakanie na aktualizačný zámok (U) – UPDATE / DELETE hľadá riadky, ktoré drží iná transakcia.

Čo s tým
Zámky a latche overené 11/2026

LCK_M_X

Čakanie na exkluzívny zámok (X) – zmena dát čaká, kým iná transakcia uvoľní riadok, stránku alebo tabuľku.

Čo s tým
  • Nájdi head blockera a jeho transakciu; dlhé transakcie skracuj.
  • Ak sa dve transakcie blokujú navzájom, vznikajú deadlocky – pozri system_health.
  • Eskalácia zámkov na celú tabuľku pri veľkých zmenách: rob ich v menších dávkach.
  • V exekučnom pláne: Plán a čakania – prečo to nie je chyba plánu
Zámky a latche overené 11/2026

LCK_M_IX

Čakanie na zámok úmyslu exkluzívneho prístupu (IX) – zmena čaká, lebo niekto drží zámok na vyššej úrovni (často celá tabuľka po eskalácii).

Čo s tým
Zámky a latche overené 11/2026

LCK_M_SCH_S

Dotaz čaká na zámok stability schémy (Sch-S) – zvyčajne preto, lebo niekto mení štruktúru tabuľky (ALTER, offline rebuild indexu).

Čo s tým
Zámky a latche overené 11/2026

LCK_M_SCH_M

Čakanie na zámok úpravy schémy (Sch-M) – ALTER, rebuild indexu alebo prepnutie partície čaká, kým dobehnú dotazy nad tabuľkou. Kým čaká, blokuje aj nové dotazy.

Čo s tým
  • Dlhý dotaz nad tabuľkou zdrží DDL a za ním sa vytvorí rad ďalších dotazov.
  • Pri online rebuild indexu pomáha WAIT_AT_LOW_PRIORITY (2014+), aby DDL nezablokoval ostatných.
  • V exekučnom pláne: Plán a čakania – prečo to nie je chyba plánu
Zámky a latche overené 11/2026

PAGELATCH_EX

Súperenie o stránku, ktorá už je v pamäti (nie je to disk) – exkluzívny latch. Typicky alokačné stránky tempdb alebo vkladanie na koniec indexu s IDENTITY.

Čo s tým
  • Ak je stránka v tempdb (database_id 2): viac dátových súborov tempdb rovnakej veľkosti (recept Konfigurácia tempdb).
  • SQL Server 2019+: memory-optimized tempdb metadata pri súperení o systémové tabuľky tempdb.
  • Vkladanie na posledný riadok indexu: OPTIMIZE_FOR_SEQUENTIAL_KEY = ON (2019+).
Zámky a latche overené 11/2026

PAGELATCH_UP

Latch v režime update na stránke v pamäti – podľa dokumentácie typicky systémové stránky PFS, GAM, SGAM. Klasický príznak súperenia o alokácie v tempdb.

Čo s tým
  • Pridaj dátové súbory tempdb (rovnaká veľkosť a rast), pozri recept Konfigurácia tempdb.
  • Nájdi, kto tempdb najviac používa (recept Kto spotrebúva tempdb).
Zámky a latche overené 11/2026

LATCH_EX

Čakanie na exkluzívny latch, ktorý nie je latchom dátovej stránky – interné štruktúry SQL Servera.

Čo s tým
  • Konkrétnu triedu latchu ukáže sys.dm_os_latch_stats (zoradiť podľa wait_time_ms).
  • Ďalší postup závisí od triedy latchu – všeobecný recept tu neexistuje.

CPU a paralelizmus

Čakanie na procesor, paralelné plány a pracovné vlákna.

CPU a paralelizmus overené 11/2026

SOS_SCHEDULER_YIELD

Úloha dobrovoľne uvoľnila procesor a čaká vo fronte, kým ho znova dostane. Veľa týchto čakaní najčastejšie znamená dotazy, ktoré skenujú veľa dát.

Čo s tým
  • Nájdi dotazy s najvyšším CPU (recept Top dotazy podľa CPU / Query Store).
  • Pozri ich plán: chýbajúci index, staré štatistiky, regresia plánu.
  • Ak je čas dotazov v poriadku, toto čakanie je očakávané a dá sa ignorovať.
  • V exekučnom pláne: Plán a čakania, RBAR
CPU a paralelizmus overené 11/2026

CXPACKET

Paralelný dotaz: vlákna sa synchronizujú alebo produkujú riadky. Samo osebe nie je chybou – ukazuje, že beží veľa paralelných plánov.

Čo s tým
  • Najprv vylaď dotazy s paralelným plánom (index, štatistiky) – paralelizmus často zakrýva sken.
  • Skontroluj cost threshold for parallelism (predvolených 5 je nízko) a MAXDOP podľa počtu jadier a NUMA.
  • Od 2016 SP2 / 2017 CU3 sa čakanie konzumentov meria zvlášť (CXCONSUMER).
  • V exekučnom pláne: Paralelizmus v pláne, cost threshold a MAXDOP
CPU a paralelizmus overené 11/2026

CXSYNC_PORT

SQL Server 2022+: paralelný plán čaká na otvorenie, zatvorenie alebo synchronizáciu portu výmeny (exchange) medzi producentmi a konzumentmi – napr. kým dobehne dlhý sort.

Čo s tým
  • Rovnaký prístup ako pri CXPACKET: plán dotazu, cost threshold for parallelism a MAXDOP.
  • V exekučnom pláne: Paralelizmus v pláne
CPU a paralelizmus overené 11/2026

THREADPOOL

Požiadavka (dotaz alebo prihlásenie) čaká na voľné pracovné vlákno. Server môže pôsobiť „zamrznuto“ – najčastejšie preto, lebo dlhé alebo blokované dotazy držia všetky vlákna.

Čo s tým
  • Pripoj sa cez DAC (admin:server) a hľadaj blokovanie a dlhé dotazy (recepty Kto koho blokuje, Dlho bežiace požiadavky).
  • Zvyšovanie max worker threads problém zvyčajne len odsunie.
  • Skontroluj aj masívny paralelizmus – každý paralelný dotaz berie viac vlákien.

Pamäť

Pridelenie pamäte dotazom (memory grant) a kompiláciám.

Pamäť overené 11/2026

RESOURCE_SEMAPHORE

Dotaz čaká na pridelenie pamäte na vykonanie (memory grant, napr. pre sort a hash), lebo ju majú iné súbežné dotazy. Pri dlhom čakaní môže skončiť chybou 8645.

Čo s tým
  • Pozri, kto čaká a koľko pamäte žiada (recept Memory grants).
  • Prehnané granty často vznikajú zo zlých odhadov riadkov – aktualizuj štatistiky, pozri plán.
  • Skontroluj max server memory a či pamäť nezaberá niečo iné.
  • V exekučnom pláne: Memory grant, Spill do tempdb
Pamäť overené 11/2026

RESOURCE_SEMAPHORE_QUERY_COMPILE

Počet súbežných kompilácií dosiahol limit a ďalšie čakajú – priveľa kompilácií, rekompilácií alebo plánov, ktoré sa nedajú uložiť do cache.

Čo s tým
  • Hľadaj ad-hoc dotazy bez parametrov (veľa jednorazových plánov v plan cache).
  • Pomôže parametrizácia dotazov v aplikácii (prípadne PARAMETERIZATION FORCED na databáze).
  • Pozri, či niečo neustále nespôsobuje rekompilácie (zmeny schémy, štatistík, SET voľby).
Pamäť overené 11/2026

CMEMTHREAD

Úloha čaká na pamäťový objekt bezpečný pre vlákna – súperenie, keď veľa úloh alokuje pamäť z toho istého objektu.

Čo s tým
  • Ojedinelé hodnoty sú bežné; rieš len trvalo vysoké.
  • Over, že je nainštalovaný najnovší CU, a hľadaj, čo robí veľa súbežných alokácií (napr. veľa kompilácií).

Sieť a externé volania

Klient nestíha čítať výsledky, linked servery a volania mimo SQL Servera.

Sieť a externé volania overené 11/2026

ASYNC_NETWORK_IO

SQL Server poslal výsledky a čaká, kým ich klient spracuje. Zvyčajne nejde o sieť, ale o aplikáciu, ktorá číta riadok po riadku alebo ťahá priveľa dát.

Čo s tým
  • Pozri, ktorá aplikácia / host čaká (recept Dlho bežiace požiadavky, sp_WhoIsActive).
  • Filtrovať treba na serveri (WHERE, TOP), nie stiahnuť všetko a filtrovať v aplikácii.
  • Až potom skontroluj sieť a samotný klientsky počítač (CPU, pamäť).
  • V exekučnom pláne: Plán a čakania
Sieť a externé volania overené 11/2026

OLEDB

Volanie OLE DB providera – najčastejšie dotaz cez linked server. Meria, ako dlho trvá volanie, nie synchronizáciu.

Čo s tým
  • Pri linked serveroch filtruj na vzdialenej strane (OPENQUERY), nech sa neprenáša celá tabuľka.
  • Pozri výkon dotazu priamo na vzdialenom serveri.

Always On / HA

Synchrónne repliky Always On AG.

Always On / HA overené 11/2026

HADR_SYNC_COMMIT

Commit na primárnej replike čaká, kým synchrónna sekundárna replika zapíše log. Pri synchrónnom režime AG je to očakávané – rieši sa len, keď je ho veľa.

Čo s tým
  • Pozri stav replík a frontu odosielania / redo (recept Always On AG).
  • Sieť medzi replikami a disk s logom na sekundári určujú, ako dlho commit čaká.
  • Vzdialenú repliku (iné dátové centrum) zvyčajne nastav na asynchrónny commit.

Bežne ignoruj 17

Úlohy na pozadí, ktoré väčšinu času spia – v štatistikách ich bežne vynechaj. Skripty na top čakania ich zvyčajne vynechávajú (napr. zoznam Paula Randala).

CPU a paralelizmus bežne ignoruj overené 11/2026

CXCONSUMER

Konzumentské vlákno paralelného plánu čaká na riadky od producenta – podľa dokumentácie bežná súčasť paralelného spracovania.

Čo s tým
Interné / benígne bežne ignoruj overené 11/2026

WAITFOR

Príkaz WAITFOR v T-SQL – čakanie, ktoré si vyžiadal sám kód.

Čo s tým
  • Ignoruj (je to zámer kódu, napr. job alebo Service Broker).