Performance

"Niewidzialny Wodospad" – Jak monitorować i rozwiązywać rywalizację o I/O w SQL Server

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:

Co powoduje parameter sniffing w SQL Server?

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.

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:

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

🧠 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.

Ghost Cleanup Task w akcji

2025-10-23 · 2 min

SQL Server przypomina organizm, który potrafi sam utrzymać czystość.
Gdy rekord zostaje usunięty, jego duch nie znika od razu — pozostaje w strukturze danych, jak ślad po zmarłej komórce.
Dopiero Ghost Cleanup Task przychodzi, by po cichu posprzątać, przywracając równowagę systemu.

To układ odpornościowy SQL Servera – działa w tle, gdy nikt nie patrzy, i dba o to, by baza nie zarosła martwymi danymi.


🔍 Zajrzyj w DMV

1
2
3
4
5
6
7
-- znajdź indeksy zawierające ghost records
SELECT 
    object_name(object_id) AS TableName, 
    index_id, 
    ghost_record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED')
WHERE ghost_record_count > 0;

„Porządek nie polega na braku chaosu, lecz na jego kontrolowaniu.” — Kant

Wewnętrzne mechanizmy pamięci SQL Server – co się dzieje w Buffer Pool

2025-10-22 · 3 min

Za każdą operacją stoi pamięć: Buffer Pool, Memory Clerks, Lazy Writer i PLE (Page Life Expectancy).
To serce SQL Servera – a każdy spadek PLE to zawał.
Zrozumienie, jak SQL zarządza stronami danych, to klucz do prawdziwego tuningu.

„Co nie zmieści się w pamięci, wróci po zemstę z dysku.”


🧠 Architektura pamięci SQL Server

SQL Server ma własny system zarządzania pamięcią – niezależny od systemu operacyjnego.
Dzięki temu może reagować szybciej i bardziej precyzyjnie na obciążenie.

Resource Governor – ogranicz CPU, nie ludzi

2025-10-21 · 2 min

Resource Governor – ogranicz CPU, nie ludzi

Nie każdy proces zasługuje na 100% CPU.
Nie każdy użytkownik powinien mieć wolną autostradę do rdzeni.
Resource Governor to strażnik równowagi – ustawia granice, zanim chaos stanie się faktem.

SQL Server potrafi być aż zbyt uprzejmy.
Jeśli aplikacja klienta zacznie mielić raporty z JOIN-ami jak spaghetti, serwer grzecznie rzuci w to wszystkie swoje wątki – a reszta użytkowników zostaje w korku.
Resource Governor mówi: dość.

DELETE vs TRUNCATE – kiedy SQL Server naprawdę sprząta

2025-10-15 · 2 min

Oba polecenia usuwają dane. Ale jedno robi to z manierą, drugie z miotłą.
DELETE i TRUNCATE wyglądają podobnie — efekt końcowy to pusta tabela.
Pod maską SQL Server jednak wykonuje zupełnie inne operacje.

DELETE – chirurg z lupą

DELETE działa wiersz po wierszu. Każdy usunięty rekord jest logowany w transakcyjnym logu (transaction log), dzięki czemu można cofnąć operację (ROLLBACK).
To daje precyzję — można użyć WHERE, aktywują się TRIGGERY, a relacje z kluczami obcymi są respektowane.
Ale cena jest jasna: log rośnie, a wydajność spada proporcjonalnie do liczby usuwanych wierszy.

Query Store i Parameter Sensitive Plan (PSP): ćwiczenia z życia

2025-10-04 · 2 min

Praktyczny przewodnik po PSP: jak zobaczyć trzy plany dla różnych zakresów parametrów, jak je stabilizować i jak diagnozować regresje w Query Store.

tempdb: kiedy i jak naprawdę ją shrinkować (bez mitów)

2025-10-04 · 2 min

Jak diagnozować rozrost tempdb i bezpiecznie ją przyciąć – krok po kroku, z gotowymi skryptami i checklistą weryfikacji.