Posts
2025-11-14 · 5 min
“Niewidzialny Wodospad” – Jak monitorować i rozwiązywać rywalizację o I/O w SQL Server
W SQL Server pod maską działa fascynująca choreografia kluczowych procesów tła, które decydują o wydajności. Chociaż Checkpoint, Lazy Writer i Log Flush mają różne zadania, wszystkie rywalizują o ten sam kluczowy zasób: podsystem I/O, którym zarządza I/O Scheduler.
Zrozumienie ich interakcji jest kluczowe, a my możemy ją “uwidocznić” za pomocą DMV i Extended Events (XE).
Klucz do zrozumienia: I/O Synchroniczne vs Asynchroniczne
Aby zrozumieć “wodospad”, musimy rozróżnić dwa typy zapisów I/O, o które walczą te procesy:
2025-11-11 · 8 min
Co powoduje parameter sniffing w SQL Server?
Mechanizm, który potrafi przyspieszyć zapytanie… albo zabić jego wydajność.
Wprowadzenie
SQL Server potrafi wykonać to samo zapytanie na dwa zupełnie różne sposoby — raz błyskawicznie, innym razem dramatycznie wolno. Przyczyną często jest zjawisko znane jako parameter sniffing.
To jeden z najczęstszych problemów wydajnościowych, a jednocześnie jedna z najgenialniejszych optymalizacji w Query Processor. Zrozumienie, skąd bierze się sniffing, to klucz do diagnozowania niestabilnych planów wykonania.
2025-11-07 · 2 min
„Monitoring to pamięć systemu.
AI to jego intuicja.”
— SQLManiak
4 grudnia 2025 poprowadzę prelekcję na Main Stage konferencji DevAI 2025.
To moment, w którym świat monitoringu, danych i generative AI spotyka się w jednym miejscu — w praktycznym scenariuszu dla każdego DBA.
Moje wystąpienie nosi tytuł:
Telemetry i Generative AI: budowa cyfrowego asystenta DBA
Jak dane z Telegrafa, InfluxDB i SQL Server można połączyć w inteligentny system rekomendacji
🔍 O czym będzie prelekcja
To 35 minut podróży po świecie, w którym telemetria przestaje być tylko metrykami,
a staje się paliwem dla inteligentnego asystenta wspierającego pracę administratora SQL.
2025-11-05 · 2 min
„Nie wystarczy wiedzieć, że działa. Trzeba wiedzieć, dlaczego działa.”
— SQLManiak
SQL Server to nie tylko tabele, indeksy i zapytania.
To ogromny silnik, który nieustannie walczy o porządek w chaosie danych — zapisując, odtwarzając, kompresując i kontrolując każdy bajt.
Dlatego rusza nowa seria: Inside SQL Server 2022 🎬
Projekt, który ma pokazać wnętrze silnika — tak, jak widzi je system, nie administrator.
🔍 O czym jest seria
W każdym odcinku zaglądamy głębiej — od struktury stron danych po log transakcyjny i mechanizm odzyskiwania.
Zamiast slajdów — czysty kod, DBCC PAGE, fn_dblog, i prawdziwe laboratorium SQL Servera 2022.
Zobaczysz, jak silnik alokuje extenty, co dzieje się w TempDB pod presją,
i dlaczego ARIES to serce każdej transakcji.
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.
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.
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.
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:
2025-10-30 · 5 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).
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.