Server je pomalý – prvých 10 minút

Hlásenie „databáza je pomalá“ je symptóm, nie diagnóza. Prvých 10 minút zbieraš fakty – **nič nemeníš**. Väčšina incidentov je jedna z piatich vecí: blokovanie, jeden drahý dotaz / zlý plán, CPU, pamäť (memory grants) alebo úložisko.

> [!CAUTION]
> Počas incidentu **nespúšťaj** `DBCC FREEPROCCACHE` ani `DBCC DROPCLEANBUFFERS` (zahodíš dôkazy a všetky dotazy sa znova kompilujú), **nereštartuj** službu „pre istotu“ (stratíš DMV, plan cache aj wait stats), nespúšťaj `KILL` bez toho, aby si vedel, čo session robí, a nemeň MAXDOP / cost threshold za behu.

## 1. Rozsah (1 min)

1. **Kto** to hlási – všetci, jedna aplikácia, jedna obrazovka? **Od kedy** – po release, po nasadení, každý deň o 9:00?
2. Je pomalý celý server, alebo len jedna databáza? Pripoj sa cez SSMS – ak sa nevieš pripojiť, skús DAC (`ADMIN:server`).
3. Zapíš si čas začiatku s časovým pásmom.

## 2. Čo práve beží (2 min)

1. [sp_WhoIsActive](script.php?id=10&s=sp-whoisactive-kto-co-prave-robi-na-serveri) (ak je nainštalovaná) – najrýchlejší celkový obraz.
2. Inak [Dlho bežiace požiadavky](script.php?id=16&s=dlho-beziace-poziadavky-co-prave-bezi) – trvanie, CPU, čítania, `wait_type`, `blocking_session_id`.
3. Je tam **blokovanie**? → [Kto koho blokuje](script.php?id=1&s=kto-koho-blokuje-blocking-chain) a [Detail blockera](script.php?id=14&s=detail-blockera-aj-spiaca-session-s-otvorenou-transakciou). Spiaca session s otvorenou transakciou je klasika.

## 3. Na čo server čaká práve teraz (1 min)

Spusti [Wait stats – rozdiel za N sekúnd](script.php?id=49&s=wait-stats-rozdiel-za-n-sekund) s 30 sekundami. Kumulatívne čísla od reštartu ([Wait stats](script.php?id=6&s=wait-stats-na-co-server-caka)) krátky problém neukážu.

| Dominantný wait | Kam ďalej |
|---|---|
| `LCK_M_*` | blokovanie – krok 2 |
| `CXPACKET` / `CXCONSUMER` + vysoké CPU | paralelné drahé dotazy – krok 4 |
| `SOS_SCHEDULER_YIELD`, vysoký podiel signal waitov | CPU – krok 4 |
| `RESOURCE_SEMAPHORE` | memory grants – krok 5 |
| `PAGEIOLATCH_*`, `WRITELOG` | úložisko – krok 6 |
| `PAGELATCH_*` na `2:x:x` | tempdb contention – krok 7 |
| `HADR_SYNC_COMMIT` | synchrónna AG replika nestíha – [AG stav](script.php?id=42&s=always-on-ag-stav-replik-a-synchronizacie) |

## 4. CPU (2 min)

1. [CPU história (ring buffer)](script.php?id=48&s=cpu-historia-za-posledne-4-hodiny-ring-buffer) – berie CPU **SQL Server**, alebo **iný proces** na stroji? Ak iný proces, problém je mimo SQL (antivírus, zálohovací agent, iná inštancia).
2. Ak SQL: [Top 20 dotazov podľa CPU](script.php?id=5&s=top-20-dotazov-podla-cpu) a [Query Store – top CPU](script.php?id=25&s=query-store-top-dotazy-podla-cpu) v cieľovej databáze. Po release pozri [Query Store – regresie](script.php?id=26&s=query-store-regresie-24-h-vs-predoslych-24-h).

## 5. Pamäť (1 min)

[Memory grants](script.php?id=19&s=memory-grants-kto-caka-na-pamat-resource-semaphore) – čakajú requesty na pamäť? Často je príčina v zlom odhade riadkov (štatistiky, parameter sniffing), nie v malej RAM. Celkový obraz: [Pamäť SQL Servera a OS](script.php?id=24&s=pamat-sql-servera-a-os-rychly-prehlad).

## 6. Úložisko (1 min)

[I/O latencia podľa súborov](script.php?id=23&s=i-o-latencia-podla-databazovych-suborov) – hodnoty sú kumulatívne, takže pri incidente porovnaj dva odbery. Log nad ~5 ms zápisu alebo dáta nad ~20 ms čítania → over s tímom storage / virtualizácie, čo sa deje na ich strane.

## 7. tempdb (1 min)

[Kto spotrebúva tempdb](script.php?id=20&s=kto-spotrebuva-tempdb) a pri RCSI / snapshot aj [Version store – kto ho drží](script.php?id=57&s=version-store-kto-ho-drzi).

## 8. Rozhodnutie a záznam (1 min)

- Ak je jasný vinník (blocker, jeden dotaz), dohodni zásah s vlastníkom aplikácie – a zapíš, čo si urobil.
- Ak jasný nie je, zbieraj ďalej: `sp_BlitzFirst @Seconds = 30` (First Responder Kit, Brent Ozar Unlimited, MIT), Extended Events, perfmon.

**Šablóna záznamu incidentu** (rovnaká ako v [Prvej pomoci DBA](script.php?id=47&s=prva-pomoc-dba-ktory-skript-spustit-pri-probleme)): server, databáza, prostredie, čas začiatku a konca s časovým pásmom, symptóm, spustené dotazy, merané okno, dominantný wait, vykonané kroky a výsledok.

> [!TIP]
> Po incidente si ulož výstupy (bez citlivých údajov) a porovnaj s normálnym dňom – „normál“ je najlepší podklad na budúce porovnanie.

## Zdroje

- [sys.dm_os_wait_stats](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql)
- [SQL high CPU troubleshooting – RING_BUFFER_SCHEDULER_MONITOR (Microsoft PFE blog, archív)](https://learn.microsoft.com/en-us/archive/blogs/sql_pfe_blog/sql-high-cpu-scenario-troubleshooting-using-sys-dm_exec_query_stats-and-ring_buffer_scheduler_monitor-ring-buffer-in-sys-dm_os_ring_buffers)
- [SQL Server First Responder Kit (Brent Ozar Unlimited, MIT)](https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit)
- [sp_WhoIsActive (Adam Machanic, GPL-3.0)](https://github.com/amachanic/sp_whoisactive)