Dwa z najbardziej atrakcyjnych mechanizmów optymalizatora zapytań Oracle Database 12c – „cardinality feedback” i „adaptive cursor sharing” – do prawidłowego działania wymagają (o czym często ze zdziwieniem przekonują się administratorzy) przełączenia parametru inicjalizacyjnego STATISTICS_LEVEL na poziom "ALL" (domyślnie "TYPICAL"). Przy takim ustawieniu gromadzone są dodatkowe wskaźniki wydajnościowe: Plan Execution Statistics i Timed OS Statistics (zainteresowanych tym, jakie wskaźniki są gromadzone przy różnych ustawieniach kieruję do analizy wyniku zapytania "select statistics_name, description, activation_level from v$statistics_level").
Ponieważ często powraca do nas pytanie o wielkość dodatkowych narzutów systemowych związanych z aktywacją gromadzenia tych dodatkowych wskaźników (a np. Burleson pisze tylko „there will be extra overhead „), to z tego powodu postanowiliśmy przeprowadzić eksperyment na rzeczywistym systemie. Eksperyment polegał na serii powtarzanych pomiarów sumarycznego czasu odpowiedzi (DB Time) serwera Oracle Database 12.2 na następującą prostą mieszankę 250 tysięcy operacji SQL: 15% pełne odczyty dużych tabel, 25% pełne odczyty małych tabel, 30% odczyty indeksowe punktowe, 30% odczyty indeksowe zakresowe.
Oto rezultaty:
– STATISTICS_LEVEL=TYPICAL: średni DB Time = 506 s
– STATISTICS_LEVEL=ALL: średni DB Time = 512 s
Dodatkowy narzut systemowy związany z przełączeniem STATISTICS_LEVEL na "ALL" wyniósł zatem tylko 1.2%. Wydaje się zatem, że kosztuje to mniej, niż wyniósłby zysk, jaki w systemie „mocno zaniedbanym” moglibyśmy osiągnąć dzięki lepszej optymalizacji zapytań. Oczywiście nasz eksperyment ma wyłącznie charakter poglądowy i jest uwarunkowany sprzętem, skomplikowaniem struktury bazy danych, specyfiką zapytań SQL, itp.
PS. Uwaga – STATISTICS_LEVEL=ALL zwiększa także ilość informacji rejestrowanych w snapshotach AWR, więc przy okazji należy liczyć się z większym zużyciem miejsca w przestrzeni tabel SYSAUX.
