ustawia się w pliku INIT...

Odnośniki

Smutek to uczucie, jak gdyby się tonęło, jak gdyby grzebano cię w ziemi.

ORA - przyp. tłum) do wartości z przedziału 10 do 50.
Podsumowując trzeba odpowiedzieć na pytanie o to, dlaczego optymalizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze - należy podkreślić, że zła decyzja dotycząca planu wykonania to raczej wyjątek niż reguła. Przykłady z niniejszego podrozdziału pokazują, że kolumny są rozpatrywane raczej indywidualnie niż grupowo. Gdyby tak było, w pierwszym z prezentowanych przykładów optymalizator kosztowy stwierdziłby - bez konieczności odtworzenia indeksu przez administratora jako unikatowego - że każdy wiersz posiada unikatowe wartości. Przykład drugi pokazuje, że jeśli kilka kolumn indeksu posiada małą liczbę różnych dopuszczalnych wartości, a polecenie SQL żąda dostępu do większości z nich, to optymalizator kosztowy często pomija taki indeks. Dzieje się tak, mimo że rozpatrywane razem kolumny są ściśle określone i zapytanie zwróci niewiele wierszy.
Nieco usprawiedliwiając działanie optymalizatora należy stwierdzić, że użycie indeksów o mniejszej ilości kolumn często daje znaczny wzrost wydajności wykonywania w porównaniu
z użyciem indeksów o wielu kolumnach.
Problem piąty: złączanie zbyt wielu tabel
Pierwsze wersje optymalizatora kosztowego często wykorzystywały metodę ,,dziel i rządź" w sytuacji, gdy złączaniu podlegało więcej niż pięć tabel. Rozpatrzmy przykład przedstawiony na rysunku 1. Zapytanie wybiera wszystkie dane związane z przedsiębiorstwem o identyfikatorze rachunku (kolumna acct_id) równym 777818. Przedsiębiorstwo posiada kilka oddziałów, a zapytanie dotyczy oddziału znajdującego się w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to acct_address, zaś tabela G to address.
WHERE acct id=77818
rysunek
Rysunek 1. Złączenie siedmiu tabel
Użytkownik oczekuje, że zapytanie zwróci stosunkowo niedużą liczbę wierszy z różnych tabel, a czas odpowiedzi nie będzie przekraczał l sekundy. Najlepiej jest, jeśli system Oracle otrzymuje wiersze z tabeli acct_address odpowiadające danemu rachunkowi, a następnie złącza ją z tabelą address w celu określenia tego, czy adresy odpowiadają stanowi Waszyngton.
Jednakże ze względu na to, że złączeniu podlega tak wiele tabel, optymalizator kosztowy często decydował będzie o tym, że przetwarzane będą tabele F i G niezależnie od pozostałych i dopiero na końcu dane zostaną scalone. Rezultatem złączenia tabel F i G będzie to, że będą musiały zostać wybrane wszystkie adresy, które dotyczą stanu Waszyngton. Proces ten może zająć nawet kilka minut, co zapewne spowoduje, że ogólny czas wykonania będzie dużo dłuższy od tego, który miałby miejsce, gdyby system Oracle sterował dostępem do wszystkich tabel od tabeli A.
Zakładając, że tabela acct_address (F) posiada indeks w kolumnie acct_id, można problem ten rozwiązać wykorzystując odpowiednią wskazówkę instruującą optymalizator kosztowy, że użyty powinien zostać ten właśnie indeks. Znacznie zwiększy to wydajność.
Co interesujące - optymalizator regułowy ma często dużo większe problemy z poprawnym określeniem planu wykonania w przypadku złączania wielu tabel niż optymalizator kosztowy.
Optymalizator regułowy często w ogóle nie używa tabeli acct jako tabeli sterującej. Aby to wymusić, należy w wyrażeniu FROM nazwę tabeli A umieścić jako ostatnią.
Jeśli wykorzystywane jest gotowe oprogramowanie, najlepszym sposobem może być utworzenie perspektywy zawierającej wskazówkę (o ile jest to dopuszczalne i możliwe w przypadku używanego pakietu).
Problem szósty: nieodpowiednie ustawienia parametrów w pliku
INIT.ORA
W wielu ośrodkach korzysta się z przedprodukcyjnej bazy danych w celu przetestowania wydajności wykonywania poleceń SQL jeszcze przed przeniesieniem indeksów i kodu do bazy produkcyjnej. W idealnej sytuacji baza przedprodukcyjna zawiera ilość danych bliską bazie produkcyjnej, a ponadto jej tabele są analizowane dokładnie w ten sam sposób, co w przypadku bazy produkcyjnej. Taka przedprodukcyjna baza stanowić często będzie kopię faktycznych plików danych fazy produkcyjnej.
Kiedy administratorzy testują zmiany w bazie przedprodukcyjnej, zwykle wszystko działa prawidłowo, jednak po przejściu do bazy produkcyjnej czasem okazuje się, że obierane są inne plany wykonania. Powodem takich problemów mogą być różne ustawienia parametrów w plikach INIT.ORA bazy przedprodukcyjnej i produkcyjnej.
Autor spotkał kiedyś znajdujące się poniżej polecenie uaktualnienia danych, którego czas wykonania sięgał czterech minut, pomimo że warunek umieszczony w wyrażeniu WHERE
odwoływał się do klucza głównego tabeli. Co dziwniejsze - kiedy z tabeli acct pobierano dane (SELECT), nie zaś uaktualniano (UPDATE), przy użyciu dokładnie takiego samego wyrażenia WHERE okazywało się, że indeks był używany.
UPDATE acct SET proc_flag = ‘Y’
WHERE pkey = 100;
# Czas odpowiedzi wynosił 4 minuty