DBPLUS Performance Monitor 2026.2 – więcej kontroli nad wydajnością i alertami
Artur Boguszewski
Wersja DBPLUS Performance Monitor 2026.2 wprowadza usprawnienia w monitoringu baz danych Oracle, Microsoft SQL Server, PostgreSQL oraz SAP HANA. Aktualizacja koncentruje się przede wszystkim na rozbudowie modułu alertów, rozszerzeniu REST API, raportowaniu statystyk wydajnościowych oraz zwiększeniu wygody zarządzania dużymi środowiskami.
Jedną z najważniejszych zmian w wersji 2026.2 jest rozbudowa procesu obsługi alertów. Każde zdarzenie alertowe otrzymuje obecnie jeden z trzech statusów:
Status New informuje o nowym zdarzeniu wymagającym uwagi. Jeżeli w kolejnym snapie warunki alertu nadal są spełnione, jego status zostaje zmieniony na In Progress. Pozwala to łatwo odróżnić nowe problemy od zdarzeń, które trwają już od dłuższego czasu.
Alert otrzymuje status Close, gdy monitorowana wartość przestanie przekraczać określony próg. Domyślnie wymagane są co najmniej dwa następujące po sobie snapy, w których warunki problemu nie są już spełnione. Mechanizm ogranicza ryzyko przedwczesnego zamknięcia alertu spowodowanego chwilową poprawą lub krótkotrwałym wahaniem wartości.
Liczbę snapów wymaganych do automatycznego zamknięcia alertu można zmienić w jego konfiguracji. Informacja o aktualnym statusie jest również dostępna przez REST API w odpowiedzi endpointu /alerts, w polu AlertStatus.
Rozszerzono konfigurację wysyłki wiadomości o alertach. Powiadomienie może zostać przesłane między innymi:
Dostępność poszczególnych opcji zależy od tego, czy konfiguracja dotyczy alertu typu Online, czy Load Trends. Pozwala to ograniczyć liczbę niepotrzebnych wiadomości i lepiej dopasować komunikację do znaczenia oraz czasu trwania problemu.
W wersjach dla Oracle i SQL Server można tworzyć alerty na podstawie statystyk Performance Counters. SQL Server umożliwia dodatkowo wykorzystanie liczników systemu operacyjnego, czyli OS Counters.
Próg alertu może być porównywany z:
Funkcja pozwala wykrywać nietypowe zachowanie instancji i serwera bez ograniczania się wyłącznie do standardowych metryk obciążenia.
Funkcjonalność Work Tags została rozszerzona na dodatkowe obszary aplikacji. Tagi pozwalają oznaczać zarówno pojedyncze zdarzenia, jak i całe przedziały czasu związane z określonymi działaniami w środowisku.
Za pomocą tagów można opisywać między innymi:
Do tej pory znaczniki były dostępne przede wszystkim na głównym wykresie obciążenia instancji. Po aktualizacji są widoczne również na ekranach:
Tagi można dodawać i przeglądać z poziomu interfejsu aplikacji za pomocą funkcji Manage Timeline. Zarządzanie zdarzeniami może być również automatyzowane przez REST API. Endpoint /worktags umożliwia pobieranie informacji, natomiast /worktagmanage pozwala tworzyć, modyfikować i usuwać wpisy
Wersja 2026.2 rozszerza zakres danych i operacji dostępnych przez REST API.
Nowy endpoint Queries udostępnia informacje o najbardziej obciążających zapytaniach. Dane mogą być wykorzystywane w zewnętrznych dashboardach, raportach, narzędziach diagnostycznych i procesach optymalizacyjnych.
Dla SQL Server i PostgreSQL dodano także endpoint SpaceSize, umożliwiający pobieranie informacji o wykorzystaniu przestrzeni przez monitorowane zasoby.
Integracja InstanceManage została rozszerzona o możliwość zmiany hasła użytkownika monitoringu. Ułatwia to automatyzację rotacji poświadczeń oraz realizację procedur bezpieczeństwa.
Poprawiono również działanie endpointu Dashboard w sytuacjach, gdy część danych monitorujących jest chwilowo niedostępna.
Jedną z najważniejszych zmian w monitoringu Oracle jest nowy mechanizm grupowania zapytań SQL. Pozwala on prezentować jako jeden wpis zapytania o identycznej lub bardzo podobnej treści, które różnią się jedynie wartościami literałów.
Przykładem mogą być zapytania:
SELECT * FROM ORDERS WHERE ORDER_ID = 1001;
SELECT * FROM ORDERS WHERE ORDER_ID = 1002;
SELECT * FROM ORDERS WHERE ORDER_ID = 1003;
Mimo że każde z nich posiada inny tekst i inną wartość literału, z punktu widzenia procesu biznesowego realizują tę samą operację. Grupowanie umożliwia analizę ich łącznego wpływu na wydajność bazy danych zamiast przeglądania wielu niemal identycznych wpisów.
Mechanizm jest szczególnie przydatny w środowiskach generujących dużą liczbę dynamicznych zapytań z literałami oraz w przypadku zapytań oznaczonych mechanizmem MARKHOT.
Użytkownik może przełączać się pomiędzy dwoma trybami:
Grupy zapytań są oznaczone dedykowaną ikoną w kolumnie Wartość skrótu. W szczegółach SQL można przejść od statystyk całej grupy do danych pojedynczych zapytań, wyświetlić wszystkie wersje zawierające literały oraz automatycznie podświetlić różnice między tekstami SQL.
Rozwiązanie poprawia czytelność ekranów monitorowania i pozwala szybciej ustalić, czy źródłem obciążenia jest cały typ operacji biznesowej, czy tylko określona wersja zapytania.
Informacje o liczbie i rozmiarze plików ArchivedLog są obecnie zapisywane w repozytorium DBPLUS.
Dzięki temu użytkownik otrzymuje dostęp do danych historycznych również wtedy, gdy nie są one już dostępne bezpośrednio na monitorowanej instancji. Domyślny wykres przedstawia okres ostatnich 14 dni i umożliwia analizę zapytań generujących logi w wybranym dniu.
W wersji 2026.2 wprowadzono również kilka zmian poprawiających codzienną pracę:
Odświeżanie uprawnień użytkownika monitoringu jest obecnie dostępne bezpośrednio z interfejsu aplikacji. Dostęp do funkcji może być kontrolowany za pomocą uprawnień w menu Security.
Dodano również możliwość określania dodatkowych parametrów connection string podczas podłączania instancji lub edycji istniejącej konfiguracji.
Poprawiono wykorzystanie pamięci przez usługę DBPLUSCATCHER w środowiskach generujących dużą liczbę zapytań z literałami pobieranych z kolejki XEvents.
Wprowadzono również poprawkę w module Space Monitor dotyczącą aktualizacji logicznych nazw i ścieżek plików.
Wdrożono dodatkowy proces applier/writer, odpowiedzialny za bezpieczne zapisywanie danych diagnostycznych do repozytorium.
Jeżeli repozytorium DBPLUS jest chwilowo niedostępne, dane zbierane z monitorowanych instancji są zapisywane lokalnie w plikach na serwerze aplikacji. Po przywróceniu dostępności repozytorium proces automatycznie odczytuje dane z bufora i zapisuje brakujące snapshoty.
Mechanizm obejmuje między innymi:
Dane są przechowywane w katalogu:
C:\ProgramData\DBPLUS\DPM.Postgres.Web\Appliers
Proces działa niezależnie i równolegle względem standardowego monitoringu. Zmniejsza ryzyko utraty danych podczas krótkotrwałych problemów z dostępnością repozytorium i zachowuje ciągłość zbierania informacji.
Administrator może konfigurować:
Domyślny czas przechowywania plików wynosi sześć godzin. Informacje o działaniu procesu są dostępne w menu Servers monitor > Logs, w zakładce Applier/writer procedure runtime.
DBPLUS Performance Monitor 2026.2 ułatwia śledzenie cyklu życia alertów, analizowanie zapytań oraz integrację z zewnętrznymi systemami.
Nowe funkcje zwiększają niezawodność monitoringu, upraszczają zarządzanie dużymi środowiskami i pozwalają lepiej powiązać problemy wydajnościowe ze zmianami wykonywanymi w infrastrukturze.
