DataPlatform

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.

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 FROMustala źródła danych, sprawdza połączenia (JOIN), a następnie przechodzi przez kolejne etapy: