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ą.
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.
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.
Premiera SQL Server 2025 przynosi zestaw zmian, które realnie wpływają na codzienną pracę administratorów, architektów oraz deweloperów baz danych. To nie jest edycja typu „poprawki i kosmetyka”. To największy krok naprzód od czasu SQL Server 2019 i 2022 – szczególnie w obszarze automatycznej optymalizacji, bezpieczeństwa oraz obserwowalności.
Poniżej znajduje się przegląd najważniejszych nowości, które faktycznie robią różnicę w środowiskach produkcyjnych.
SQL Server 2025 wprowadza moduł Adaptive Workload Intelligence.
To rozbudowana warstwa predykcyjnej optymalizacji, która:
“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:
Mechanizm, który potrafi przyspieszyć zapytanie… albo zabić jego wydajność.
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.
„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
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.
„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.
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.
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).
Nowy plan kompilowany jest m.in. gdy:
RECOMPILE, OPTION (RECOMPILE)),DBCC FREEPROCCACHE). | |
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.
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).
Nowy plan kompilowany jest m.in. gdy:
RECOMPILE, OPTION (RECOMPILE)),DBCC FREEPROCCACHE). | |
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.