STATISTICS_LEVEL=ALL – zyski vs. koszty

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[…]

Jak bardzo statystyki systemowe wpływają na wybór planu wykonania?

Wiemy, że statystyki systemowe są ważnym opisem wydajności wykorzystywanej platformy sprzętowej oraz że kosztowy optymalizator zapytań Oracle Database odwołuje się do ich wartości podczas szacowania kosztów planów wykonania zapytań (pisaliśmy o statystykach systemowych TU). Wielu administratorów zastanawia się jednak, jak bardzo optymalizator zapytań jest „wrażliwy” na wartości tych statystyk (zbieranych metodami eksperymentalnymi). Aby odpowiedzieć na[…]

Podstawy Oracle Database: uwaga na koszt planu wykonania zapytania!

Czas rozprawić się ze zbyt często powtarzaną herezją, zanim stanie się prawdą… Elementem techniki kosztowej optymalizacji zapytań jest szacowanie kosztów alternatywnych planów wykonania zapytania. Odbywa się ono automatycznie podczas przetwarzania polecenia SQL przez optymalizator zapytań. Plan wykonania, którego szacowany koszt okazał się najniższy ze wszystkich rozważanych, jest wybierany jako plan do realizacji. Programista ma możliwość[…]

Jak nie pomylić się za pierwszym razem? Adaptatywne plany wykonania w Oracle Database 12c

Zajmowaliśmy się już kiedyś ciekawą kwestą korygowania nieoptymalnego planu wykonania z wykorzystaniem Cardinality Feedback (Jak optymalizator uczy się na błędach). Pokazaliśmy, że po pierwszym wykonaniu nieoptymalnego planu wykonania optymalizator potrafi go zmodyfikować tak, aby drugie wykonanie przebiegło już bardziej efektywnie. Niestety, ten mechanizm serwera potrafi być skuteczny dopiero przy drugim wywołaniu tego samego zapytania. Pierwsze[…]

Profile czy hinty?

Zarówno SQL Profiles, jak i Hints to mechanizmy pozwalające sterować zachowaniem optymalizatora  zapytań tak, aby wydajność generowanych planów była jak najlepsza. Byłyby one niepotrzebne, gdyby optymalizator potrafił zawsze trafnie wybrać optymalny plan wykonania. Ponieważ jednak nierzadko zdarza się optymalizatorowi „chybić”, to takie lekarstwa są niezbędne. Hinty to zapisane w treści polecenia SQL wskazówki (zalecenia), instruujące[…]

Jak możemy chronić się przed pogorszeniem planu wykonania?

Nierzadko spotykamy się z problemem gwałtownego pogorszenia wydajności starej, wielokrotnie sprawdzonej i zoptymalizowanej aplikacji. Przyczyną zwykle jest upgrade oprogramowania serwera bazy danych, zmiana sposobu zbierania statystyk dla optymalizatora zapytań, rekonfiguracja optymalizatora zapytań czy zmiana ustawień systemowych. Czy można jakoś uchronić się przed takimi wydajnościowymi niespodziankami w przyszłości? Istnieje mechanizm serwera bazy danych Oracle Database umożliwiający[…]

A czy pamiętasz o statystykach systemowych?

Jak wiemy, aby trafnie estymować koszty planów wykonania zapytań, optymalizator zapytań wymaga obecności szeregu statystyk (modeli statystycznych). Statystyki te dzielą się na cztery kategorie: (1) statystyki opisujące tabele (liczba rekordów, liczba bloków, średni rozmiar rekordu), (2) statystyki opisujące indeksy (liczba bloków liści, liczba poziomów, współczynnik klastrowania), (3) statystyki opisujące kolumny tabel (liczba wartości, liczba wartości[…]

Jak optymalizator Oracle Database uczy się na błędach (Cardinality Feedback)

Podczas estymacji kosztu planu wykonania zapytania, kosztowy optymalizator zapytań musi m.in. oszacować liczby rekordów (tzw. kardynalność), które będą przetwarzane przez zapytanie w różnych fazach jego realizacji. Od precyzji tych szacunków zależą decyzje dotyczące np. kolejności łączenia tabel czy też wyboru algorytmu łączenia tabel. Szacunki kardynalności są dokonywane przede wszystkim na podstawie dostępnych statystyk dla tabel[…]

Dlaczego 99 ze 100 to tylko 1%?

W bazie danych umieszczamy tabelę zawierającą sto rekordów, które w kolumnie PŁEĆ posiadają 99 razy wartość ‘M’ i jeden raz wartość ‘K’. Gromadzimy statystyki dla tej tabeli, gromadzimy histogram dla kolumny PŁEĆ. Następnie wykonujemy zapytanie, które w klauzuli WHERE posiada predykat UPPER(PŁEĆ) = ‘M’. Jaka jest selektywność tego predykatu? Oczywiście 99%. Jaką selektywność oszacuje optymalizator[…]

Gdy brakuje (niektórych) statystyk dla optymalizatora

W jaki sposób kosztowy optymalizator zapytań estymuje koszt planu wykonania zapytania jeśli administrator/programista nie zadbał o zgromadzenie statystyk dla optymalizatora? Wcześniejsze wersje serwerów Oracle Database przełączały się wtedy w tryb optymalizacji regułowej. Serwer Oracle Database 11g skorzysta w tej sytuacji z tzw. dynamicznego próbkowania (dynamic sampling), polegającego na pobraniu losowej próbki bloków tabel uczestniczących w[…]