Jak sprawdzić rzeczywiste wykorzystanie plików danych i logu transakcyjnego?

2026-08-11 · 3 min

Praktyczne zapytania T-SQL pokazujące rozmiar, zajętość i wolne miejsce w plikach danych oraz logu transakcyjnym SQL Server.

Autogrowth jest włączony, a plik bazy nadal się nie rozszerza. Jak to możliwe?

2026-08-04 · 12 min

Autogrowth w SQL Server nie gwarantuje, że plik bazy danych zawsze się rozszerzy. Sprawdź najczęstsze przyczyny, zapytania diagnostyczne i dobre praktyki zarządzania przestrzenią.

SQL Server Agent, Backup i Restore: dwa praktyczne przewodniki dla DBA

2026-07-27 · 8 min

Dwa praktyczne e-booki dla administratorów SQL Server: automatyzacja i kontrola jobów SQL Server Agent oraz kompletna strategia backupu, restore, RPO, RTO i procedur awaryjnych.

SQL Server Backup: zielony job to jeszcze nie strategia odtwarzania

2026-06-07 · 5 min

Zielony status joba backupu w SQL Server Agent to dopiero początek. Prawdziwa strategia zaczyna się wtedy, gdy umiemy odtworzyć bazę do właściwego punktu w czasie i w akceptowalnym czasie.

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.

DevAI 2025 – prelekcja na Main Stage: Telemetry + AI + SQL Server

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.

Inside SQL Server 2022 – start serii na YouTube

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.

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

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.

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 · 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).

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):

1. Tworzy wpis logu z informacją o zmianie (LSN – Log Sequence Number),
2. Wpis trafia na dysk (flush logu),
3. 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.

PAGE Restore – chirurgia bazy danych

2025-10-24 · 3 min

Kiedy baza ma miliardy stron danych, pełny restore bywa jak przeszczep serca.
Ale czasem wystarczy precyzyjna operacja – przywrócenie tylko uszkodzonej strony.
PAGE restore to chirurgiczna procedura SQL Servera: przywraca fragment, nie zatrzymując całego organizmu.

🧩 Idea

Każdy obiekt w SQL Server składa się z 8-KB stron.
Gdy jedna z nich zostanie uszkodzona (błąd I/O, dysk, checksum), silnik oznacza ją jako suspect i pozwala na przywrócenie tylko tej strony z backupu — bez pełnego przywracania całej bazy czy pliku danych.

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ść.

Audyt uprawnień – kto, co i kiedy?

2025-10-20 · 5 min

Zaufanie jest dobre, ale SERVER AUDIT jest lepszy.
Audyt pozwala Ci wiedzieć, kto nadał, odebrał lub zmienił uprawnienia w Twojej bazie.
Nie potrzebujesz narzędzi firm trzecich — wszystko masz wbudowane w SQL Server.
Wystarczy kilka poleceń: CREATE SERVER AUDIT, CREATE DATABASE AUDIT SPECIFICATION, i masz pełny ślad bezpieczeństwa.

„Bez logu nie ma dowodu. Bez dowodu nie ma bezpieczeństwa.”

Dlaczego audyt?

Uprawnienia to władza. A każda władza powinna zostawiać ślady.
W systemach z wieloma administratorami (lub z zespołem deweloperów z prawami sysadmina) często nie sposób ustalić, kto co zmienił.
Audyt pozwala przywrócić porządek i odpowiedzialność.

FCI czy AlwaysOn AG – jak SQL trzyma fason po awarii

2025-10-19 · 2 min

FCI (Failover Cluster Instance) chroni instancję, AG (AlwaysOn Availability Groups) chroni dane.
Oba mają swoje miejsce, oba swoje pułapki.
FCI to wspólny storage i klasyczna niezawodność. AG to elastyczność, replikacja i odczyty.

„Awaria to egzamin z tego, jak myślałeś, zanim się zaczęła.”

Architektura i filozofia

FCI to jeden serwer logiczny rozłożony na kilka węzłów klastra.
Jeśli jeden padnie – cały SQL „przenosi się” na inny, korzystając z tego samego storage’u.
To oznacza: zero utraty danych, ale pełna zależność od wspólnego magazynu.
W skrócie – chronisz instancję, nie bazę.

Backup VLDB >4TB – jak nie wpaść w pułapkę

2025-10-18 · 3 min

Przy małej bazie backup to prosty przycisk.
Przy bazie 4 TB i więcej — to strategia.

SQL Server potrafi wykonać kopię dowolnej wielkości bazy, ale granicą staje się infrastruktura: I/O, sieć, tempdb, a czasem… ludzkie złudzenie, że „backup się zrobi”.

W świecie VLDB (Very Large Database) backup nie jest operacją — to proces logistyczny.
Wymaga planowania, testów, segmentacji i chłodnej kalkulacji: ile danych, w jakim czasie, dokąd i po co.

Dobry DBA nie zgaduje – obserwuje

2025-10-17 · 3 min

Każdy wykres to historia.
CPU, I/O, pamięć, zapytania – wszystkie mówią, co naprawdę dzieje się na serwerze.
Dobry DBA nie reaguje na alarm, tylko rozumie, dlaczego on się pojawił.

Mój ulubiony zestaw: Telegraf + InfluxDB + Grafana.
Z tego powstaje cockpit — SQLManiak Monitoring.
Nie dashboard „bo ładny”, tylko mapa świadomości systemu, w której każda metryka ma znaczenie.

„Wiedza zaczyna się tam, gdzie kończą się zgadywania.”

Od reakcji do obserwacji

Większość problemów z wydajnością nie pojawia się nagle.
One dojrzewają. Rosną cicho, pomiędzy kolejnymi BACKUP, CHECKDB, i zbyt długim SELECT *.
Bez monitoringu widzimy tylko skutek – czerwony alert, rosnące czasy odpowiedzi, spadek PLE.

Ghost Records – duchy w bazie danych

2025-10-16 · 3 min

W bazie danych straszy.
Nie w horrorze, ale w DMV: sys.dm_db_index_physical_stats.
Gdy kasujesz wiersz, SQL Server nie usuwa go od razu — zostawia ducha (ghost record), który czeka, aż ghost cleanup task wykona egzorcyzm.

To dzięki temu ROLLBACK może przywrócić dane, a DELETE nie musi blokować świata.
System woli oznaczyć rekord jako „martwy”, niż ryzykować chaos w strukturze stron danych.

„To, czego nie widzisz, nie znaczy, że tego nie ma — zwłaszcza w bazie danych.”

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.

Co widzi Query Processor zanim Ty klikniesz Execute?

2025-10-14 · 3 min

Kiedy wpisujesz SELECT i wciskasz „Execute”, zaczyna się coś magicznego. Ale nie w takiej kolejności, jak myślisz.

SQL Server nie jest naiwnym tłumaczem Twojego kodu – to kompilator logiki zapytań, który widzi świat zupełnie inaczej. Zanim linijka SELECT dotrze do procesora zapytań, tekst T-SQL zostaje zanalizowany, przepisany, znormalizowany i zoptymalizowany. Efektem nie jest „wykonanie kodu”, ale plan zapytania – precyzyjna instrukcja dla silnika relacyjnego, jak dobrać dane możliwie najtaniej.

I właśnie tu pojawia się pierwszy paradoks: SQL Server wcale nie zaczyna od SELECT.
Najpierw patrzy na FROM – ustala źródła danych, sprawdza połączenia (JOIN), a następnie przechodzi przez kolejne etapy:

Dwadzieścia lat w drodze: o nauczaniu, ciekawości i przyszłości technologii

2025-10-13 · 2 min

Dwadzieścia lat temu, w czasach, gdy świat IT pachniał świeżością Windows Server 2003, a SQL Server 2000 dopiero uczył nas, czym naprawdę jest baza danych, dostałem e-mail z tytułem, który miał odmienić mój zawodowy los:
“Congratulations, you are now a Microsoft Certified Trainer.”

Nie przypuszczałem, że to zaproszenie do jednej z najdłuższych i najpiękniejszych podróży mojego życia.
Wtedy byłem po prostu młodym pasjonatem technologii, który uwielbiał rozumieć jak to działa.
Dziś wiem, że to zdanie wciąż najlepiej mnie opisuje.