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.
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.
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ść.
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ść.
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ę.
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.
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.”
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.
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:
2025-10-04 · 2 min
Masz wrażenie, że SHRINKFILE na pliku log nic nie daje? Tu jest kompletna mapa pułapek: VLF, otwarte transakcje, brak backupów logu i nieuśpione replikacje.
2025-10-04 · 1 min
Praktyczny szablon rozwiązywania incydentów (Problem–Information–Options–Select–Execute–Evaluate) z przykładami dla SQL Server.
2025-10-04 · 1 min
Krótkie i skuteczne: jak wydłużyć historię zadań, sprzątać ją automatycznie, oraz zakładać alerty i operatorów bez klikania.
2025-10-04 · 2 min
Jak diagnozować rozrost tempdb i bezpiecznie ją przyciąć – krok po kroku, z gotowymi skryptami i checklistą weryfikacji.
