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.
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-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.
2025-10-04 · 1 min
Praktyczna strategia backupu/restore dla bardzo dużych baz: striped backup, kompresja, MAXTRANSFERSIZE, BUFFERCOUT.
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
Prosty przykład many‑to‑many z tabelą łącznikową, która ma własne kolumny (Grade, EnrolledDate) i walidację po stronie UI.
2025-10-04 · 1 min
Porównanie w praktyce: kiedy FCI, kiedy AG, i jak policzyć RTO/RPO bez zgadywania. Proste scenariusze decyzyjne.
2025-10-04 · 1 min
Zbieramy metryki IIS (requests/sec, queue length, HTTP 500) i logi z access.log do InfluxDB 2.x z użyciem Telegrafa.
