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.