Przez dekady budziliśmy się w nocy, gdy zadanie DBMS_STATS nie zdążyło się wykonać przed otwarciem biznesu. Oracle Real-Time Statistics zmienia reguły gry, ale czy naprawdę możemy zapomnieć o klasycznym zbieraniu statystyk?
- Real-Time Statistics zbiera informacje o danych podczas operacji DML, eliminując opóźnienie między zmianą danych a aktualizacją statystyk
- Mechanizm przechowuje dane w pamięci SGA i utrwala je w słowniku danych, co minimalizuje narzut wydajnościowy
- Klasyczny DBMS_STATS pozostaje niezbędny dla histogramów, statystyk kolumnowych i pełnej analizy rozkładu danych
- Największe korzyści widać w środowiskach ETL oraz systemach z intensywnymi operacjami bulk load
Problem nieaktualnych statystyk w praktyce
Każdy doświadczony DBA zna ten scenariusz: nocne zadanie ETL ładuje miliony wierszy do tabeli stagingowej, a poranne raporty działają fatalnie, ponieważ optymalizator wciąż widzi tabelę jako pustą lub zawierającą dane z poprzedniego dnia. Statystyki zebrane o północy nie odzwierciedlają rzeczywistości o 8 rano.
W klasycznym modelu mieliśmy do czynienia z cyklicznym procesem: dane się zmieniają, statystyki starzeją się, plany wykonania degradują, zbieramy statystyki, sytuacja się poprawia, i cykl zaczyna się od nowa. W środowiskach OLTP z tysiącami transakcji na sekundę ta pętla potrafiła powodować poważne problemy wydajnościowe.
Architektura Real-Time Statistics
Oracle wprowadził Real-Time Statistics w wersji 19c, choć pełna funkcjonalność pojawiła się dopiero w 21c. Mechanizm działa na zasadzie przechwytywania informacji o zmianach danych podczas wykonywania operacji DML, bez konieczności dodatkowego skanowania tabel.
Kluczowe elementy architektury obejmują:
- Zbieranie statystyk podczas operacji INSERT, UPDATE, DELETE oraz MERGE
- Przechowywanie danych tymczasowych w pamięci SGA w dedykowanym obszarze
- Automatyczne utrwalanie w słowniku danych (tabele SYS.WRI$_OPTSTAT_*)
- Integrację z Cost Based Optimizer poprzez rozszerzone struktury statystyk
Statystyki czasu rzeczywistego obejmują przede wszystkim liczność wierszy (row count) oraz informacje o wartościach granicznych (min/max). To właśnie te podstawowe metryki mają największy wpływ na szacowanie kardynalności.
Co dokładnie zbiera Oracle w czasie rzeczywistym
Mechanizm koncentruje się na informacjach, które można efektywnie aktualizować inkrementalnie. Podczas operacji DML Oracle śledzi:
- Całkowitą liczbę wierszy w tabeli
- Liczbę bloków poniżej znacznika wysokiej wody (HWM)
- Wartości minimalne i maksymalne dla kolumn indeksowanych
- Przybliżoną liczbę wartości unikalnych (NDV) dla wybranych kolumn
Z mojego doświadczenia wynika, że Real-Time Statistics najlepiej sprawdzają się w scenariuszach bulk load, gdzie jednorazowo ładujemy setki tysięcy wierszy. W typowym OLTP z drobnymi transakcjami różnica jest mniej zauważalna, ponieważ klasyczne statystyki rzadko zdążą się zdezaktualizować na tyle, by wpłynąć na plany wykonania.
Wpływ na Cost Based Optimizer
Optymalizator Oracle wykorzystuje Real-Time Statistics jako uzupełnienie klasycznych statystyk DBMS_STATS. Podczas generowania planu wykonania CBO sprawdza najpierw, czy dostępne są statystyki czasu rzeczywistego, i jeśli tak, używa ich do korekty szacunków kardynalności.
Proces wygląda następująco: optymalizator pobiera bazowe statystyki ze słownika danych, następnie sprawdza dostępność Real-Time Statistics w pamięci SGA, koryguje szacunki liczności na podstawie aktualnych informacji i generuje plan wykonania z użyciem skorygowanych wartości.
Możemy zweryfikować wykorzystanie tego mechanizmu analizując plan wykonania. W sekcji Note pojawi się informacja "real-time statistics used" gdy optymalizator faktycznie skorzystał z aktualnych danych.
Monitorowanie i diagnostyka
Oracle udostępnia kilka widoków do monitorowania Real-Time Statistics. Widok DBA_TAB_STATS_HISTORY pokazuje historię zmian statystyk, natomiast V$SQL_PLAN zawiera informacje o wykorzystaniu statystyk czasu rzeczywistego w konkretnych planach.
Przydatne zapytanie diagnostyczne pozwala sprawdzić, które tabele korzystają z Real-Time Statistics. Wystarczy połączyć informacje z DBA_TABLES z danymi z widoków dynamicznych, filtrując po znaczniku wskazującym na obecność statystyk czasu rzeczywistego.
Parametr OPTIMIZER_REAL_TIME_STATISTICS kontroluje działanie mechanizmu na poziomie sesji lub instancji. Domyślnie jest włączony w Oracle 19c i nowszych.
Scenariusz produkcyjny: hurtownia danych
W jednym z projektów hurtowni danych mieliśmy tabelę faktów, do której codziennie ładowano około 50 milionów wierszy. Proces ETL kończył się o 6 rano, a zbieranie statystyk trwało kolejne 2 godziny. Użytkownicy zaczynający pracę o 7 widzieli dramatycznie wolne raporty.
Po migracji do Oracle 19c z włączonymi Real-Time Statistics sytuacja uległa znaczącej poprawie. Optymalizator natychmiast widział aktualną liczność tabeli, co eliminowało najgorsze pomyłki w szacowaniu kardynalności. Czas odpowiedzi porannych raportów spadł średnio o 60%.
Real-Time Statistics kontra Dynamic Sampling
Oba mechanizmy służą poprawie jakości decyzji optymalizatora, ale działają odmiennie. Dynamic Sampling wykonuje rzeczywiste zapytania próbkujące podczas parsowania SQL, co wprowadza dodatkowy narzut. Real-Time Statistics korzysta z informacji już zebranych, bez dodatkowego obciążenia w momencie optymalizacji.
Dynamic Sampling lepiej sprawdza się przy złożonych predykatach i korelacjach między kolumnami, natomiast Real-Time Statistics doskonale obsługują podstawowe szacunki liczności po masowych zmianach danych.
Ograniczenia, o których musisz wiedzieć
Real-Time Statistics nie zastępują pełnego procesu zbierania statystyk. Mechanizm nie zbiera histogramów, które są kluczowe dla kolumn o nierównomiernym rozkładzie wartości. Nie aktualizuje również statystyk rozszerzonych ani statystyk dla wyrażeń.
Dodatkowo mechanizm ma ograniczoną skuteczność dla operacji DELETE, gdzie dokładne śledzenie zmian jest bardziej skomplikowane. W przypadku dużej liczby usunięć wciąż zalecam okresowe przebudowanie statystyk klasyczną metodą.
Czy DBMS_STATS odchodzi do lamusa?
Absolutnie nie. Real-Time Statistics to wartościowe uzupełnienie, ale nie zamiennik klasycznego procesu. Nadal potrzebujemy DBMS_STATS do zbierania histogramów, statystyk systemowych, statystyk dla tabel tymczasowych oraz pełnej analizy rozkładu danych w kolumnach.
Moja rekomendacja: utrzymuj harmonogram DBMS_STATS dla pełnego zbierania statystyk, ale możesz wydłużyć interwały i zmniejszyć agresywność zbierania, pozwalając Real-Time Statistics obsługiwać bieżące zmiany wolumenu danych.