1. Zmiany w statystykach

Statystyki są niezbędne dla optymalizatora Oracle do określenia najbardziej efektywnego planu wykonania zapytania. Są one bowiem źródłem informacji o dystrybucji i charakterystyce danych w tabelach i indeksach. Gdy statystyki ulegają zmianie – w wyniku działań takich jak dodawanie nowych danych, usuwanie istniejących rekordów lub wykonywanie zaplanowanych aktualizacji – zmienia się również spojrzenie optymalizatora na dane. Może to skłonić Oracle do ponownej oceny bieżącego planu wykonania, co potencjalnie prowadzi do sytuacji w której Oracle zmienia plan wykonania.

Dlaczego ma to znaczenie? W praktyce częste zmiany statystyk mogą prowadzić do znacznej zmienności wydajności zapytań. Oznacza to, że administratorzy baz danych i deweloperzy muszą zwracać baczną uwagę na to, kiedy i w jaki sposób statystyki są aktualizowane. Musi to być jednak proces przemyślany, umożliwiający utrzymanie stabilnej i przewidywalnej wydajności zapytań. Regularne monitorowanie i dostosowywanie może być konieczne, zwłaszcza gdy dochodzi do dużego obciążenia lub usunięcia danych. Zwłaszcza jeśli chce się zapobiec spadkowi wydajności i zapewnić, że plany wykonania pozostaną wydajne.

2. Zmiany w dystrybucji danych

Nawet jeśli statystyki pozostają niezmienione, rzeczywista dystrybucja danych w tabelach może subtelnie zmieniać się w tym czasie. Powodem mogą być różne czynniki, takie jak aktualizacje istniejących rekordów lub dodanie nowych, jeszcze nieuwzględnionych typów danych. Wpływa to na szacunki kardynalności – przewidywania dotyczące liczby wierszy danych, na które prawdopodobnie wpłynie zapytanie. Przewidywania te są krytyczne dla optymalizatora Oracle przy podejmowaniu decyzji o najbardziej efektywnym planie wykonania.

Dlaczego jest to istotne? Oszacowania kardynalności wpływają na decyzje o tym, których indeksów użyć, czy wykonać pełne skanowanie tabeli i jak połączyć tabele w zapytaniach wielotabelowych. Jeśli założenia optymalizatora dotyczące dystrybucji danych są błędne, może on wybrać plan, który nie jest już optymalny.

Okresowy przegląd i dostosowanie założeń optymalizatora to sposób, w jaki można sobie z tym poradzić. Może to obejmować częstsze aktualizacje statystyk lub korzystanie z funkcji takich jak dynamiczne próbkowanie – pozwala to Oracle lepiej ocenić rzeczywistą dystrybucję danych w czasie wykonywania. Informowanie optymalizatora o rzeczywistym stanie dystrybucji danych może pomóc w zapewnieniu, że podejmuje on decyzje w oparciu o najbardziej dokładne i aktualne informacje.

3. Zmiany w parametrach bazy danych

Parametry takie jak optimizer_mode dyktują sposób, w jaki optymalizator podchodzi do planów wykonania. Tryb ten można ustawić na wartości takie jak ALL_ROWS w celu optymalizacji wydajności zapytań dla wszystkich zwracanych wierszy lub FIRST_ROWS w celu nadania priorytetu szybkości zwracania początkowych wierszy. Zmiana tych parametrów może zmienić sposób przetwarzania zapytań. To z kolei wpływa na wybrane plany wykonania.

Modyfikacja innych parametrów, takich jak optimizer_index_cost_adj, który dostosowuje szacunkowy koszt dostępu do indeksu, lub optimizer_index_caching, który wpływa na zakładany procent bloków indeksu w pamięci podręcznej, może również drastycznie zmienić plan wykonania. Zmiany te rekalibrują sposób, w jaki optymalizator waży różne strategie wykonania, w efekcie Oracle zmienia plan wykonania.

4. Zmiany w obiektach schematu

• Zmiany indeksów: Gdy dodawane są nowe indeksy, zapewniają one optymalizatorowi dodatkowe ścieżki – zwykle bardziej wydajne niż te dostępne wcześniej. Jak można się spodziewać, usunięcie indeksu działa w drugą stronę. Może to zmusić optymalizator do powrotu do mniej wydajnego skanowania tabeli. Modyfikacja indeksu, taka jak zmiana jego kolumn lub typu (np. z b-drzewa na indeks bitmapowy), może również zmienić jego przydatność dla niektórych typów zapytań, powodując ponowną ocenę najlepszej strategii wykonania.
• Rola ograniczeń: Ograniczenia, takie jak klucze podstawowe, klucze obce i unikalne ograniczenia, dostarczają optymalizatorowi informacji o unikalności i integralności danych. Mogą one potencjalnie wpływać na metody łączenia i wykorzystanie indeksów podczas optymalizacji zapytań. Zmiany w ograniczeniach mogą skłonić optymalizator do dostosowania założeń dotyczących dystrybucji danych, co z kolei wpływa na plan wykonania.

5. Podgląd zmiennej powiązanej (Bind variable peeking)

Bind variable peeking to funkcja, w której optymalizator Oracle sprawdza rzeczywiste wartości zmiennych bind podczas pierwszego wykonania instrukcji SQL. Celem jest określenie najbardziej wydajnego planu wykonania i umożliwienie optymalizatorowi utworzenia planu dostosowanego do potrzeb. Planu, który uwzględnia specyfikę danych, na których będzie operował.

Zazwyczaj użycie zmiennych wiążących w zapytaniach SQL promuje stabilność planu i możliwość ponownego użycia, unikając trudnego analizowania dla każdego wykonania. Jednak początkowe wykonanie pozwala optymalizatorowi „zajrzeć” do rzeczywistych wartości wiązania, co może mieć wpływ na wybrany plan. Na przykład zapytanie, które filtruje kolumnę z wysoce zdeformowaną dystrybucją danych, może prowadzić do różnych ścieżek wykonania. Wszystko zależy od wartości użytej w czasie parsowania.

Wpływ wartości stałych dosłownych (Literals)

Zastąpienie zmiennych bind wartościami dosłownymi zmienia tę dynamikę. Optymalizator generuje plan dla każdego unikalnego zestawu wartości literalnych, co może prowadzić do wielu planów dla zasadniczo tego samego zapytania. Chociaż może to zoptymalizować wydajność w określonych przypadkach, może również zwiększyć narzut analizowania i zmniejszyć ogólną wydajność z powodu braku współdzielenia planu.

6. Adaptive Cursor Sharing

Gdy zapytanie jest wykonywane po raz pierwszy, Oracle tworzy domyślny plan wykonania na podstawie bieżących statystyk i początkowych wartości zmiennych wiążących. Gdy zapytanie jest wykonywane wielokrotnie z różnymi wartościami zmiennych wiążących, optymalizator zbiera dane dotyczące wydajności. W tym samym czasie ocenia, czy początkowy plan jest nadal skuteczny, czy też potrzebne są poprawki. Jeśli wykryte zostaną znaczące różnice w wydajności, optymalizator może wygenerować wiele planów wykonania dla tego samego zapytania, a każdy z nich zostanie zoptymalizowany dla określonego zakresu wartości zmiennej wiążącej.

7. Bug w optymalizatorze – Oracle zmienia plan wykonania

Zdarza się to rzadko, ale się zdarza – optymalizator Oracle nie jest odporny na okazjonalne błędy. Naturalnie, jeden z nich może być przyczyną nieoczekiwanej nieefektywności planów wykonania. Gdy wystąpią, czy to z powodu błędów w bazie kodu optymalizatora, czy też nieprzewidzianych interakcji między różnymi częściami systemu bazy danych, mogą generować nieoptymalne plany. Plany takie nie wykorzystują efektywnie dostępnych indeksów lub wykonują więcej kosztownych operacji niż jest to konieczne.

W tym wypadki, nie ma innego rozwiązania niż zidentyfikowanie błędu. Wymaga to dokładnych testów i obserwacji, zwłaszcza jeśli zapytanie, które wcześniej działało wydajnie, nagle wykazuje spadek wydajności bez widocznej przyczyny.

8. Obecność podpowiedzi

Podpowiedzi w zapytaniach Oracle SQL służą jako instrukcje, które kierują wyborami optymalizatora, często zastępując jego domyślny proces decyzyjny. Osadzając podpowiedzi bezpośrednio w instrukcji SQL, programiści mogą wpływać na ścieżkę obraną przez optymalizator, na przykład określając, które indeksy mają być używane, dyktując metody łączenia lub kierując kolejnością złączeń tabel.

Zmiany w samych podpowiedziach mogą również prowadzić do zmian w planach wykonania. Na przykład, usunięcie wcześniej uwzględnionej podpowiedzi może przywrócić optymalizator do pierwotnego planu, który może być mniej wydajny w oparciu o bieżące środowisko danych. Podobnie, modyfikowanie podpowiedzi w celu odzwierciedlenia nowych strategii indeksowania lub różnych podejść do łączenia może radykalnie zmienić sposób wykonywania zapytania.

9. Mała ilość próbek podczas zbierania statystyk

Bez wystarczających statystyk optymalizator może nie być w stanie podejmować świadomych decyzji dotyczących najlepszych planów wykonania zapytań. Gdy rozmiar próby jest zbyt mały lub nie jest reprezentatywny dla pełnego zbioru danych, wynikowe statystyki mogą nie odzwierciedlać dokładnie prawdziwej natury danych.

Może to prowadzić do niedokładnych szacunków kardynalności. Błędnie oszacowana kardynalność może z kolei wprowadzać w błąd optymalizator, wtedy Oracle zmienia plan wykonania na potencjalnie mniej wydajny. Na przykład, optymalizator może wybrać pełne skanowanie tabeli, gdy skanowanie indeksu byłoby bardziej wydajne, lub może nieprawidłowo ułożyć złączenia z powodu nieprawidłowych założeń dotyczących rozmiaru i dystrybucji danych.

10. Zmienne wartości danych

W bazach danych Oracle zmienne wartości danych to te, które są tymczasowe lub podlegają szybkim zmianom.

Gdy wartości danych w kolumnie są zmienne, statystyki optymalizatora mogą niedokładnie odzwierciedlać aktualny stan danych w czasie wykonywania zapytania. Ta rozbieżność może prowadzić do niedopasowania między oczekiwaną a rzeczywistą dystrybucją danych, powodując, że optymalizator wybierze nieoptymalne plany wykonania. Plan zoptymalizowany pod kątem określonego zakresu wartości może działać słabo, jeśli wartości te zmieniają się szybko i nieprzewidywalnie.

Optymalizator napotyka dodatkowe wyzwania w przypadku danych krótkotrwałych, w których wartości mogą istnieć tylko przez krótki czas, zanim zostaną zaktualizowane lub usunięte. W takich przypadkach proces decyzyjny optymalizatora, oparty na statystykach gromadzonych w rutynowych odstępach czasu, może pozostawać w tyle za rzeczywistym scenariuszem danych, prowadząc do częstych zmian planu. Powodem jest to, że optymalizator próbuje ponownie skalibrować swoją strategię, aby dostosować ją do najnowszych charakterystyk danych.

11. Asynchroniczne zbierane statystyki

W bazach danych Oracle, asynchroniczne zbieranie statystyk jest metodą używaną do zbierania statystyk dystrybucji danych bez przerywania normalnego działania bazy danych. Podejście to jest szczególnie przydatne w środowiskach wysokiej dostępności, gdzie minimalizacja przestojów jest głównym celem. Ale zawsze jest jakieś „ale”.

Opóźnienie w aktualizacjach statystyk spowodowane asynchronicznym zbieraniem oznacza, że optymalizator może nie mieć najbardziej aktualnych danych podczas określania najlepszego planu wykonania. Może to skutkować wyborem planów, które nie są zoptymalizowane pod kątem bieżącej dystrybucji danych. W ten sposób uzyskujemy nieefektywną wydajność zapytań.