Posts

Kiedy SQL Server kompiluje nowy plan zapytania?

2025-11-03 · 1 min

SQL Server jest sprytny. Nie kompiluje planów za każdym razem — robi to tylko wtedy, gdy naprawdę musi.
Za każdym wykonaniem zapytania optymalizator najpierw zagląda do plan cache. Jeśli znajdzie pasujący plan – użyje go ponownie (to tzw. re-use).

🔍 Kiedy powstaje nowy plan?

Nowy plan kompilowany jest m.in. gdy:

brak pasującego planu w cache,
zmieniły się statystyki (AUTO_UPDATE_STATISTICS),
użyto opcji zmieniającej kontekst (RECOMPILE, OPTION (RECOMPILE)),
parametry zmieniły selektywność (i włącza się Parameter Sensitive Plan Optimization),
lub plan został usunięty z cache (np. po DBCC FREEPROCCACHE).

🧠 Jak to podejrzeć?

1
2
3
4
5
6
7
8
9
-- podejrzyj, ile planów trzyma SQL Server
SELECT COUNT(*) AS PlansInCache FROM sys.dm_exec_cached_plans;

-- zobacz najczęściej używane plany
SELECT TOP 10 usecounts, objtype, cacheobjtype, size_in_bytes / 1024 AS KB,
       DB_NAME(st.dbid) AS DatabaseName, st.text
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
ORDER BY usecounts DESC;

🧩 Dlaczego to ważne?

Częste rekompilacje = niepotrzebne zużycie CPU.
Z kolei zbyt agresywne ponowne używanie planów może prowadzić do parameter sniffing.
Balans pomiędzy tymi zjawiskami to jedna z tajemnic wydajności SQL Servera.

Kiedy SQL Server kompiluje nowy plan zapytania?

2025-11-03 · 1 min

🔍 Kiedy powstaje nowy plan?

Nowy plan kompilowany jest m.in. gdy:

brak pasującego planu w cache,
zmieniły się statystyki (AUTO_UPDATE_STATISTICS),
użyto opcji zmieniającej kontekst (RECOMPILE, OPTION (RECOMPILE)),
parametry zmieniły selektywność (i włącza się Parameter Sensitive Plan Optimization),
lub plan został usunięty z cache (np. po DBCC FREEPROCCACHE).

🧠 Jak to podejrzeć?

1
2
3
4
5
6
7
8
9
-- podejrzyj, ile planów trzyma SQL Server
SELECT COUNT(*) AS PlansInCache FROM sys.dm_exec_cached_plans;

-- zobacz najczęściej używane plany
SELECT TOP 10 usecounts, objtype, cacheobjtype, size_in_bytes / 1024 AS KB,
       DB_NAME(st.dbid) AS DatabaseName, st.text
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
ORDER BY usecounts DESC;

🧩 Dlaczego to ważne?

Filozofia świadomego DBA

2025-11-02 · 2 min

Świadomy DBA to nie tylko operator poleceń.
To filozof systemu – ktoś, kto rozumie przyczynę przed reakcją.

SQL Server to narzędzie, ale też nauczyciel.
Uczy pokory wobec złożoności, dyscypliny w dokumentowaniu i cierpliwości w analizie.
Pokazuje, że każda decyzja ma koszt, a każda optymalizacja ma kontekst.

Świadomość zaczyna się tam, gdzie kończy się rutyna.
Widzisz nie tylko wynik zapytania, ale jego wpływ na tempdb.
Nie tylko CPU, ale scheduler, który za nim stoi.
Nie tylko alert, ale przyczynę, która go wywołała.

Batch Mode na Rowstore – ewolucja zapytań

2025-11-01 · 2 min

SQL Server 2022 przyniósł rewolucję: Batch Mode on Rowstore.
Zamiast przetwarzać każdy wiersz osobno, silnik potrafi działać grupowo – jak procesor SIMD w świecie danych.
To ewolucja w stronę analitycznej wydajności, bez potrzeby kolumnowych indeksów.

🔍 Zajrzyj w DMV

1
2
3
4
5
-- sprawdź, które zapytania wykorzystują Batch Mode
SELECT * FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qp.query_plan.value('declare namespace p="http://schemas.microsoft.com/sqlserver/2004/07/showplan"; 
                           //p:RelOp/@Parallel', 'varchar(5)') IS NOT NULL;

⚙️ Jak to działa

Batch Mode przetwarza dane w blokach (batchach) po kilkaset wierszy zamiast rekord po rekordzie.
Każdy operator (np. agregacja, sortowanie, join) korzysta z tego samego bloku danych, dzięki czemu redukuje narzut CPU i zwiększa przepustowość.
To jak różnica między przenoszeniem cegieł po jednej a całymi paletami.

Threadpool Waits – gdy zabraknie wątków

2025-10-31 · 2 min

SQL Server jest jak organizm oddychający wątkami.
Każdy worker to oddech – bez nich system się dusi.

Gdy zobaczysz THREADPOOL w sys.dm_os_wait_stats, wiesz, że SQL Server walczy o tlen.
To nie jest zwykły wait — to moment, w którym silnik nie jest w stanie przydzielić nowych workerów,
bo wszystkie dostępne wątki zostały pochłonięte przez równoległe zadania lub blokady.

🔍 Zajrzyj w DMV

1
2
3
4
-- sprawdź obciążenie puli wątków
SELECT scheduler_id, current_tasks_count, runnable_tasks_count, active_workers_count, work_queue_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255;

📊 Interpretacja:

HOBT – hierarchia porządku danych

2025-10-30 · 6 min

Dane w SQL Serverze nie leżą luzem. Tworzą drzewa, a ich gałęzie prowadzą do stron danych.
HOBT (Heap Or B-Tree) to jednostka składowania stojąca za każdym indeksem B-tree i za każdą tabelą heap (bez klastrowanego).
To „szkielet” porządku i adresowania danych — od korzenia (root), przez poziomy pośrednie, aż po liście (leaf).

„Struktura jest formą istnienia porządku.” — SQLManiak

🧩 Co to jest HOBT w praktyce?

Każda partycja indeksu lub heap’a = jeden HOBT
(tabela 1-partycja i 3 indeksy ⇒ 4 HOBT; tabela 4-partycje i 2 indeksy ⇒ 8 HOBT).

Walec ARIES – jak SQL zapisuje historię transakcji

2025-10-29 · 3 min

SQL Server nie zapomina.
Zanim zapisze dane na dysk, zapisuje historię tego, co ma się wydarzyć.
To właśnie mechanizm ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) – serce niezawodności systemu transakcyjnego.

„Historia to pamięć systemu.” — SQLManiak

⚙️ Write-Ahead Logging (WAL)

Każda modyfikacja w SQL Serverze przechodzi przez log transakcyjny (.ldf):

Tworzy wpis logu z informacją o zmianie (LSN – Log Sequence Number),
Wpis trafia na dysk (flush logu),
Dopiero wtedy zmieniona strona danych może zostać zapisana.

To zasada Write-Ahead Logging (WAL) – najpierw log, potem dane.
Dzięki niej SQL Server wie, co się wydarzyło nawet po awarii.

TempDB – plac zabaw SQL Servera

2025-10-28 · 2 min

TempDB to laboratorium SQL Servera. Wszystko, co chwilowe – tabele tymczasowe, sortowania, wersje stron, spool’e, hash joiny, wersje snapshot isolation – trafia właśnie tam. Jeśli baza danych to umysł, TempDB jest jego warsztatem.

Brak równowagi w TempDB spowalnia cały system, jak zbyt mały blat stołu w laboratorium.

⚙️ Co trafia do TempDB

tabele tymczasowe (#local, ##global)
zmienne tabelaryczne (@table)
sortowania i hashowania (ORDER BY, GROUP BY, JOIN)
wersje stron przy snapshot isolation / RCSI
operacje DBCC CHECKDB
spool’e i worktable/workfile

🧠 Architektura TempDB

TempDB jest wspólna dla całego serwera (jedna na instancję) i odtwarza się przy restarcie.

Parameter Sensitive Plan – inteligencja kontekstowa SQL Servera

2025-10-27 · 1 min

Każdy plan zapytania to decyzja, jak przejść od danych do wyniku.
Przez lata SQL Server zapamiętywał pierwszy plan (parameter sniffing) i używał go zawsze, nawet gdy kolejne parametry miały inny rozkład danych.

💡 Co wnosi PSP (SQL Server 2022)?

Mechanizm Parameter Sensitive Plan (PSP) pozwala utrzymywać kilka wariantów planu dla tego samego zapytania, zoptymalizowanych pod różne „konteksty parametrów”.
Przy każdym wywołaniu optymalizator używa dispatcher’a, który dobiera najlepszy wariant do bieżących wartości.

Query Store – pamięć planów, pamięć błędów

2025-10-26 · 2 min

Query Store to pamięć długotrwała SQL Servera – zapisuje plany, decyzje, a czasem i pomyłki.
Dzięki niemu system potrafi uczyć się na błędach – zachowuje historię wykonania zapytań i pozwala DBA prześledzić ewolucję wydajności.
To jak pamiętnik z poprzednich dni – czasem pełen wniosków, czasem skruchy.

🧠 Jak działa Query Store

Każde zapytanie, które trafi do silnika SQL Servera, może zostać zapisane w Query Store – wraz z planem wykonania i statystykami runtime.
Z biegiem czasu serwer gromadzi wiedzę: które plany były dobre, a które doprowadziły do regresji.