Dobry monitoring to podstawa stabilnego działania środowisk bazodanowych. Porównujemy narzędzia z ponad 20 lat doświadczenia.
- Monitoring reaktywny (alerty gdy coś się stało) to za mało — potrzebny jest monitoring predykcyjny.
- Najważniejsze metryki: wait events, buffer cache hit ratio, I/O latency i top SQL by elapsed time.
- Unikaj alert fatigue — zbyt wiele alertów prowadzi do ignorowania wszystkich.
- Dobre dashboardy to nie liczby — to kontekst: co jest normą, co jest anomalią.
- Każdy monitoring powinien mieć właściciela i proces eskalacji — nie tylko narzędzie.
Monitoring reaktywny vs. predykcyjny
Większość organizacji, z którymi pracuję, ma monitoring reaktywny: alarm dzwoni, gdy coś się już posypało. Tablespace zapełniony w 100%, sesje zablokowane od godziny, backup nie wykonany od tygodnia. To lepsze niż nic — ale daleko od dobrego.
Monitoring predykcyjny to inny poziom: system ostrzega Cię, gdy tablespace wypełni się za 48 godzin przy obecnym tempie wzrostu. Gdy czas wykonania kluczowego raportu zaczyna rosnąć — 5%, 10%, 20% wolniej niż baseline. Gdy I/O latency wzrasta subtelnie, ale konsekwentnie przez trzy dni z rzędu.
Różnica między reaktywnym a predykcyjnym to różnica między byciem strażakiem a bycie inżynierem zapobiegania pożarom.
Metryki, które naprawdę mają znaczenie
Przez lata nauczyłem się, że liczy się nie ilość monitorowanych metryk, ale wybór właściwych. Dla baz Oracle i SQL Server fundamentem są:
Dla Oracle
- Top wait events — powiedzą Ci, na co baza czeka najbardziej
- Buffer cache hit ratio — poniżej 95% to sygnał do zbadania
- Library cache hit ratio — wskaźnik jakości bind variables
- Top SQL by elapsed time / CPU / I/O — złoczyńcy wydajnościowi
- Undo retention — szczególnie ważny przy długich transakcjach
Dla SQL Server
- Wait statistics — analogia Oracle wait events
- Page Life Expectancy (PLE) — zdrowie buffer pool
- Batch requests/sec + compilations/sec — obciążenie silnika
- VLF count — fragmentacja transaction log
- Index fragmentation — wpływ na wydajność odczytów
Alert fatigue — cichy zabójca monitoringu
Znam środowiska, gdzie system monitoringu wysyła 300+ alertów dziennie. Efekt? Administratorzy przestają czytać maile od systemu monitoringu. Gdy przychodzi prawdziwy alarm, ginie w szumie.
Monitoring, który wysyła zbyt wiele alertów, jest gorszy niż brak monitoringu — bo daje fałszywe poczucie bezpieczeństwa.
Recepta jest prosta, choć wymaga dyscypliny: każdy alert powinien wymagać działania. Jeśli alert przychodzi i nic nie robisz (albo robisz „kliknij OK") — to nie jest alert, to szum. Usuń go lub zmień progi.
Narzędzia w 2026 roku
Rynek narzędzi monitoringu baz danych jest bogaty. Z naszego doświadczenia:
- Oracle Enterprise Manager — najlepsze dla środowisk czysto Oracle, drogie, ale kompletne
- SolarWinds DPA — świetne cross-platform (Oracle + SQL Server), dobry UX
- Datadog / New Relic — dobre dla organizacji z szerokim stackiem observability
- Grafana + Prometheus — open-source, wymaga więcej pracy, ale pełna kontrola
- sp_WhoIsActive + własne skrypty — nie śmiej się — dla wielu firm to wystarczy
Nie ma jednego narzędzia dla wszystkich. Ważniejsze niż wybór narzędzia jest to, kto jest odpowiedzialny za alerty i jaki jest proces eskalacji.