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

Wyłączanie użycia ścieżki bezpośredniej przy pełnym odczycie tabeli (Oracle Database 11g)

Jednym z ciekawszych mechanizmów prowadzenia dyskowego wejścia/wyjścia w Oracle Database 11g jest realizacja pełnego odczytu tabeli (full table scan) metodą ścieżki bezpośredniej (direct path). Idea ścieżki bezpośredniej polega na pomijaniu bufora Buffer Cache i odczytywaniu bloków tabeli z dysku bezpośrednio do PGA. Dzięki temu możliwa jest poprawa wydajności operacji pełnego odczytu tabeli (brak narzutów związanych[…]

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

Śledzenie pracy optymalizatora zapytań Oracle Database

Działanie kosztowego optymalizatora zapytań w uproszczeniu polega na: (1) transformacji tekstu zapytania SQL, (2) generowaniu alternatywnych planów wykonania zapytania, (3) estymacji ich kosztów, (4) wyborze tego planu wykonania, którego estymowany koszt jest najniższy. Transformacja tekstu zapytania SQL może obejmować np. scalanie definicji perspektywy, „wpychanie” predykatów, rozwijanie podzapytań, przepisywanie zapytań na perspektywy materializowane. Z kolei alternatywne[…]

Jak działa Database Buffer Cache? (część 1)

Buffer Cache to obszar pamięci wewnątrz SGA pełniący rolę dwukierunkowego bufora dyskowego uczestniczącego w operacjach odczytu i zapisu obiektów użytkowników (tabele, indeksy). Jego rozmiar jest określany automatycznie lub jest narzucony przez administratora (parametr db_cache_size). Buffer Cache służy redukcji aktywności dyskowej serwera. Zanim zapytanie SQL odczyta blok danych z dysku, najpierw próbuje znaleźć ten blok w[…]