Istnieje co najmniej 11 sposobów kontrolowania planu bez modyfikowania zapytania. Są one wymienione poniżej z grubsza w kolejności przydatności:
- Podstawa planu SQL - Zastąp jeden plan innym planem.
- Profile SQL - Dodaj „korektywne” wskazówki do planów. Na przykład profil może powiedzieć „to połączenie zwraca 100 razy więcej wierszy niż oczekiwano”, co pośrednio zmienia plan.
- Przechowywany konspekt - Pomysł podobny do SQL Plan Baseline, ale z mniejszą liczbą funkcji. Ta opcja jest prostsza w użyciu, ale mniej wydajna i nie jest już obsługiwana.
- DBMS_STATS.SET_X_STATS - Ręczne modyfikowanie statystyk tabel, kolumn i indeksów może znacząco zmienić plany, sprawiając, że obiekty sztucznie wyglądają na mniej lub bardziej kosztowne.
- Kontrola sesji - Na przykład
alter session set optimizer_features_enable='11.2.0.3';. Nie zawsze są pomocne parametry. Ale jeden z parametrów OPTIMIZER_* może pomóc lub możesz zmienić plan za pomocą nieudokumentowanej wskazówki lub wyłączyć funkcję taką jak ta:alter session set "_fix_control"='XYZ:OFF'; - Kontrola systemu - Podobnie jak powyżej, ale dotyczy całego systemu.
- DBMS_SPD - Dyrektywa SQL Plan jest podobna do profilu, ponieważ zapewnia optymalizatorowi pewne informacje korygujące. Ale to działa na niższym poziomie, we wszystkich planach i jest nowością w 12c.
- DBMS_ADVANCED_REWRITE - Zmień zapytanie na inne zapytanie.
- Wirtualna prywatna baza danych - Zmień zapytanie na inne, dodając predykaty. Nie jest przeznaczony do zwiększania wydajności, ale prawdopodobnie można go nadużyć do zmiany ścieżek dostępu do indeksu.
- Struktura tłumaczeń SQL - Zmień zapytanie na inne zapytanie, zanim zostanie ono przeanalizowane. Może to umożliwić uruchomienie całkowicie „niewłaściwego” SQL.
- Poprawka SQL (dbms_sqldiag internal.i_create_patch) - Zmień zapytanie na inne zapytanie. Podobny do DBMS_ADVANCED_REWRITE, ale jest nieudokumentowany i być może nieco mocniejszy.
