Wydawnictwo Helion

ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
PRZYKADOWY ROZDZIA PRZYKADOWY ROZDZIA
IDZ DO IDZ DO
ZAMW DRUKOWANY KATALOG ZAMW DRUKOWANY KATALOG
KATALOG KSIEK KATALOG KSIEK
TWJ KOSZYK TWJ KOSZYK
CENNIK I INFORMACJE CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK ZAMW CENNIK
CZYTELNIA CZYTELNIA
FRAGMENTY KSIEK ONLINE FRAGMENTY KSIEK ONLINE
SPIS TRECI SPIS TRECI
DODAJ DO KOSZYKA DODAJ DO KOSZYKA
KATALOG ONLINE KATALOG ONLINE
Optymalizacja Oracle SQL.
Leksykon kieszonkowy
Autor: Mark Gurry
Tumaczenie: Bartomiej Garbacz
ISBN: 83-7197-983-5
Tytu oryginau: Oracle SQL Tuning. Pocket Reference
Format: B5, stron: 128
Niezoptymalizowane polecenia SQL s jednym z gwnych czynnikw powodujcych
mao wydajne dziaanie systemu bazy danych. W niniejszej ksice Mark Gurry dzieli
si z Czytelnikiem swoimi przemyleniami dotyczcymi problemu optymalizacji. Autor
prezentuje rozwizania wielu typowych problemw za pomoc wbudowanych
w Oracle'a optymalizatorw. Omawia midzy innymi:
Problem wyboru optymalizatora
Dziaanie optymalizatora reguowego (rule-based)
Dziaanie optymalizatora kosztowego (cost-based)
Problemy wsplne dla obu optymalizatorw
Optymalizacja Oracle SQL. Leksykon kieszonkowy zaoszczdzi wiele czasu
powiconego na pisanie wydajnych zapyta. Powinna si znale w biblioteczce
kadego administratora i uytkownika Oracle'a.
5RKUVTGEK
Wstp....................................................................................... 5
Optymalizatory SQI .............................................................. 9
Dziaanie optymalizatora reguowego..................................................10
Dziaanie optymalizatora kosztowego .................................................17
Czste nieporozumienia zwizane z optymalizatorami .......................25
Wybr optymalizatora..........................................................................26
Problemy i ich rozuizania
u przypadku optymalizatora reguouego ............................ 27
Problem pierwszy: nieodpowiednia tabela sterujca ...........................28
Problem drugi: nieodpowiedni indeks .................................................29
Problem trzeci: nieodpowiedni indeks sterujcy..................................30
Problem czwarty: uycie indeksu ORDER BY
zamiast indeksu WHERE.....................................................................32
Problemy i ich rozuizania
u przypadku optymalizatora kosztouego ............................ 33
Problem pierwszy: problem asymetrii .................................................33
Problem drugi: analizowanie nieodpowiednich danych.......................36
Problem trzeci: wsplne uywanie optymalizatorw przy zczeniach ..38
Problem czwarty: wybieranie nieodpowiedniego indeksu...................41
Problem pity: zczanie zbyt wielu tabel............................................44
Problem szsty: nieodpowiednie ustawienia parametrw
w pliku INIT.ORA...............................................................................45
Problemy usplne
dla optymalizatora reguouego i kosztouego....................... 51
Problem pierwszy: polecenia zapisane
w postaci uniemoliwiajcej wykorzystanie indeksw........................52
Problem drugi: brak indeksw lub nieodpowiednie indeksy ...............56
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
PRZYKADOWY ROZDZIA PRZYKADOWY ROZDZIA
IDZ DO IDZ DO
ZAMW DRUKOWANY KATALOG ZAMW DRUKOWANY KATALOG
KATALOG KSIEK KATALOG KSIEK
TWJ KOSZYK TWJ KOSZYK
CENNIK I INFORMACJE CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK ZAMW CENNIK
CZYTELNIA CZYTELNIA
FRAGMENTY KSIEK ONLINE FRAGMENTY KSIEK ONLINE
SPIS TRECI SPIS TRECI
DODAJ DO KOSZYKA DODAJ DO KOSZYKA
KATALOG ONLINE KATALOG ONLINE
Optymalizacja Oracle SQL.
Leksykon kieszonkowy
Autor: Mark Gurry
Tumaczenie: Bartomiej Garbacz
ISBN: 83-7197-983-5
Tytu oryginau: Oracle SQL Tuning. Pocket Reference
Format: B5, stron: 128
Niezoptymalizowane polecenia SQL s jednym z gwnych czynnikw powodujcych
mao wydajne dziaanie systemu bazy danych. W niniejszej ksice Mark Gurry dzieli
si z Czytelnikiem swoimi przemyleniami dotyczcymi problemu optymalizacji. Autor
prezentuje rozwizania wielu typowych problemw za pomoc wbudowanych
w Oracle'a optymalizatorw. Omawia midzy innymi:
Problem wyboru optymalizatora
Dziaanie optymalizatora reguowego (rule-based)
Dziaanie optymalizatora kosztowego (cost-based)
Problemy wsplne dla obu optymalizatorw
Optymalizacja Oracle SQL. Leksykon kieszonkowy zaoszczdzi wiele czasu
powiconego na pisanie wydajnych zapyta. Powinna si znale w biblioteczce
kadego administratora i uytkownika Oracle'a.
5RKUVTGEK
Wstp....................................................................................... 5
Optymalizatory SQI .............................................................. 9
Dziaanie optymalizatora reguowego..................................................10
Dziaanie optymalizatora kosztowego .................................................17
Czste nieporozumienia zwizane z optymalizatorami .......................25
Wybr optymalizatora..........................................................................26
Problemy i ich rozuizania
u przypadku optymalizatora reguouego ............................ 27
Problem pierwszy: nieodpowiednia tabela sterujca ...........................28
Problem drugi: nieodpowiedni indeks .................................................29
Problem trzeci: nieodpowiedni indeks sterujcy..................................30
Problem czwarty: uycie indeksu ORDER BY
zamiast indeksu WHERE.....................................................................32
Problemy i ich rozuizania
u przypadku optymalizatora kosztouego ............................ 33
Problem pierwszy: problem asymetrii .................................................33
Problem drugi: analizowanie nieodpowiednich danych.......................36
Problem trzeci: wsplne uywanie optymalizatorw przy zczeniach ..38
Problem czwarty: wybieranie nieodpowiedniego indeksu...................41
Problem pity: zczanie zbyt wielu tabel............................................44
Problem szsty: nieodpowiednie ustawienia parametrw
w pliku INIT.ORA...............................................................................45
Problemy usplne
dla optymalizatora reguouego i kosztouego....................... 51
Problem pierwszy: polecenia zapisane
w postaci uniemoliwiajcej wykorzystanie indeksw........................52
Problem drugi: brak indeksw lub nieodpowiednie indeksy ...............56
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
PRZYKADOWY ROZDZIA PRZYKADOWY ROZDZIA
IDZ DO IDZ DO
ZAMW DRUKOWANY KATALOG ZAMW DRUKOWANY KATALOG
KATALOG KSIEK KATALOG KSIEK
TWJ KOSZYK TWJ KOSZYK
CENNIK I INFORMACJE CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK ZAMW CENNIK
CZYTELNIA CZYTELNIA
FRAGMENTY KSIEK ONLINE FRAGMENTY KSIEK ONLINE
SPIS TRECI SPIS TRECI
DODAJ DO KOSZYKA DODAJ DO KOSZYKA
KATALOG ONLINE KATALOG ONLINE
Optymalizacja Oracle SQL.
Leksykon kieszonkowy
Autor: Mark Gurry
Tumaczenie: Bartomiej Garbacz
ISBN: 83-7197-983-5
Tytu oryginau: Oracle SQL Tuning. Pocket Reference
Format: B5, stron: 128
Niezoptymalizowane polecenia SQL s jednym z gwnych czynnikw powodujcych
mao wydajne dziaanie systemu bazy danych. W niniejszej ksice Mark Gurry dzieli
si z Czytelnikiem swoimi przemyleniami dotyczcymi problemu optymalizacji. Autor
prezentuje rozwizania wielu typowych problemw za pomoc wbudowanych
w Oracle'a optymalizatorw. Omawia midzy innymi:
Problem wyboru optymalizatora
Dziaanie optymalizatora reguowego (rule-based)
Dziaanie optymalizatora kosztowego (cost-based)
Problemy wsplne dla obu optymalizatorw
Optymalizacja Oracle SQL. Leksykon kieszonkowy zaoszczdzi wiele czasu
powiconego na pisanie wydajnych zapyta. Powinna si znale w biblioteczce
kadego administratora i uytkownika Oracle'a.
5RKUVTGEK
Wstp....................................................................................... 5
Optymalizatory SQI .............................................................. 9
Dziaanie optymalizatora reguowego..................................................10
Dziaanie optymalizatora kosztowego .................................................17
Czste nieporozumienia zwizane z optymalizatorami .......................25
Wybr optymalizatora..........................................................................26
Problemy i ich rozuizania
u przypadku optymalizatora reguouego ............................ 27
Problem pierwszy: nieodpowiednia tabela sterujca ...........................28
Problem drugi: nieodpowiedni indeks .................................................29
Problem trzeci: nieodpowiedni indeks sterujcy..................................30
Problem czwarty: uycie indeksu ORDER BY
zamiast indeksu WHERE.....................................................................32
Problemy i ich rozuizania
u przypadku optymalizatora kosztouego ............................ 33
Problem pierwszy: problem asymetrii .................................................33
Problem drugi: analizowanie nieodpowiednich danych.......................36
Problem trzeci: wsplne uywanie optymalizatorw przy zczeniach ..38
Problem czwarty: wybieranie nieodpowiedniego indeksu...................41
Problem pity: zczanie zbyt wielu tabel............................................44
Problem szsty: nieodpowiednie ustawienia parametrw
w pliku INIT.ORA...............................................................................45
Problemy usplne
dla optymalizatora reguouego i kosztouego....................... 51
Problem pierwszy: polecenia zapisane
w postaci uniemoliwiajcej wykorzystanie indeksw........................52
Problem drugi: brak indeksw lub nieodpowiednie indeksy ...............56
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
PRZYKADOWY ROZDZIA PRZYKADOWY ROZDZIA
IDZ DO IDZ DO
ZAMW DRUKOWANY KATALOG ZAMW DRUKOWANY KATALOG
KATALOG KSIEK KATALOG KSIEK
TWJ KOSZYK TWJ KOSZYK
CENNIK I INFORMACJE CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK ZAMW CENNIK
CZYTELNIA CZYTELNIA
FRAGMENTY KSIEK ONLINE FRAGMENTY KSIEK ONLINE
SPIS TRECI SPIS TRECI
DODAJ DO KOSZYKA DODAJ DO KOSZYKA
KATALOG ONLINE KATALOG ONLINE
Optymalizacja Oracle SQL.
Leksykon kieszonkowy
Autor: Mark Gurry
Tumaczenie: Bartomiej Garbacz
ISBN: 83-7197-983-5
Tytu oryginau: Oracle SQL Tuning. Pocket Reference
Format: B5, stron: 128
Niezoptymalizowane polecenia SQL s jednym z gwnych czynnikw powodujcych
mao wydajne dziaanie systemu bazy danych. W niniejszej ksice Mark Gurry dzieli
si z Czytelnikiem swoimi przemyleniami dotyczcymi problemu optymalizacji. Autor
prezentuje rozwizania wielu typowych problemw za pomoc wbudowanych
w Oracle'a optymalizatorw. Omawia midzy innymi:
Problem wyboru optymalizatora
Dziaanie optymalizatora reguowego (rule-based)
Dziaanie optymalizatora kosztowego (cost-based)
Problemy wsplne dla obu optymalizatorw
Optymalizacja Oracle SQL. Leksykon kieszonkowy zaoszczdzi wiele czasu
powiconego na pisanie wydajnych zapyta. Powinna si znale w biblioteczce
kadego administratora i uytkownika Oracle'a.
5RKUVTGEK
Wstp....................................................................................... 5
Optymalizatory SQI .............................................................. 9
Dziaanie optymalizatora reguowego..................................................10
Dziaanie optymalizatora kosztowego .................................................17
Czste nieporozumienia zwizane z optymalizatorami .......................25
Wybr optymalizatora..........................................................................26
Problemy i ich rozuizania
u przypadku optymalizatora reguouego ............................ 27
Problem pierwszy: nieodpowiednia tabela sterujca ...........................28
Problem drugi: nieodpowiedni indeks .................................................29
Problem trzeci: nieodpowiedni indeks sterujcy..................................30
Problem czwarty: uycie indeksu ORDER BY
zamiast indeksu WHERE.....................................................................32
Problemy i ich rozuizania
u przypadku optymalizatora kosztouego ............................ 33
Problem pierwszy: problem asymetrii .................................................33
Problem drugi: analizowanie nieodpowiednich danych.......................36
Problem trzeci: wsplne uywanie optymalizatorw przy zczeniach ..38
Problem czwarty: wybieranie nieodpowiedniego indeksu...................41
Problem pity: zczanie zbyt wielu tabel............................................44
Problem szsty: nieodpowiednie ustawienia parametrw
w pliku INIT.ORA...............................................................................45
Problemy usplne
dla optymalizatora reguouego i kosztouego....................... 51
Problem pierwszy: polecenia zapisane
w postaci uniemoliwiajcej wykorzystanie indeksw........................52
Problem drugi: brak indeksw lub nieodpowiednie indeksy ...............56
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Problem trzeci: korzystanie ze scalania indeksu jednokolumnowego .59
Problem czwarty: bdne uycie ptli zagniedonych,
sortowania i czenia lub zcze haszujcych ....................................61
Problem pity: bdne uycie IN, EXISTS, NOT IN, NOT EXISTS
lub zcze tabel...................................................................................63
Problem szsty: niepotrzebne sortowanie............................................69
Problem sidmy: zbyt wiele indeksw dla tabeli.................................72
Problem smy: uycie OR zamiast UNION ........................................74
Problem dziewity: tabele i indeksy z wieloma wierszami usunitymi ..75
Inne problemy: intensywne uywanie perspektyw..............................78
Inne problemy: zczanie zbyt wielu tabel...........................................78
Drobne porady dotyczce strojenia polece SQI................. 78
Identyfikowanie zego kodu SQL ........................................................79
Identyfikowanie dugo wykonujcych si polece SQL......................80
Uycie polecenia DECODE dla instrukcji wyboru IF/ELSE...............81
Zmienne dowizane .............................................................................82
Korzystanie ze uskazuek SQI ........................................... 84
Ignorowanie wskazwek......................................................................85
Korzystanie ze wskazwek w perspektywach .......................................86
Dostpne wskazwki............................................................................86
Wykorzystanie pakietu DBMS_STATS
do zarzdzania danymi statystycznymi................................. 108
Uycie pakietu DBMS_STATS do przyspieszenia procesu analizy..108
Kopiowanie statystyk przy uyciu pakietu DBMS_STATS..............109
Manipulowanie statystykami przy uyciu pakietu DBMS_STATS ..110
Przywracanie poprzedniej wersji statystyk ........................................111
Wykorzystanie scenariuszy
dla spjnych planu uykonania........................................ 112
Rejestrowanie scenariuszy .................................................................112
Udostpnianie scenariuszy.................................................................114
Zarzdzanie scenariuszami.................................................................115
Skorouidz............................................................................ 119
2TQDNGO[KKEJTQ\YK\CPKC
YRT\[RCFMW
QRV[OCNK\CVQTCMQU\VQYGIQ
Optymalizator kosztowy uleg znaczcemu ulepszeniu w porwnaniu
ze swoj pierwotn wersj. Autor sugeruje, aby w kadym orodku,
w ktrym od niedawna uywa si systemu Oracle, korzystano wanie
z optymalizatora kosztowego. Ponadto warto pomyle take o tym,
aby w orodkach, w ktrych korzysta si obecnie z optymalizatora re-
guowego, przygotowano stosowny plan migracji do optymalizatora
kosztowego. Istniej jednak pewne kwestie zwizane z tym rodzajem
optymalizatora, o ktrych trzeba pamita. W tabeli 3 wymieniono
najczciej powtarzajce si problemy (wraz z czstotliwoci ich wy-
stpowania), jakie Autorowi udao si zaobserwowa.
Tabela 3. Czsto powtarzajce si problemy w przypadku optymalizatora
kosztowego
Problem Przypadkw
1. Problem asymetrii 30%
2. Analizowanie nieodpowiednich danych 25%
3. Wsplne uywanie optymalizatorw przy zczeniach 20%
4. Wybieranie nieodpowiedniego indeksu 20%
5. Zczanie zbyt wielu tabel < 5%
6. Nieodpowiednie ustawienia parametrw w pliku INIT.ORA < 5%
2TQDNGORKGTYU\[RTQDNGOCU[OGVTKK
Zamy, e problem dotyczy systemu, w ktrym istnieje tabela
trans o jednej z kolumn noszcej nazw status. Dopuszczalne s
dwie wartoci kolumny: O dla oznaczenia transakcji otwartych (open
transactions), ktre nie zostay jeszcze zaksigowane, oraz C dla ozna-
czenia transakcji zamknitych (closed transactions), ktre zostay ju
zaksigowane i nie wymagaj dalszej obsugi. Istnieje ponad milion
rekordw, ktre posiadaj status C i zawsze tylko 100 wierszy, ktre
maj status O.
Utworzono nastpujce polecenie SQL, ktre jest wykonywane co-
dziennie kilkaset razy, jednak czas odpowiedzi nie jest zadowalajcy:
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = 'O';
Czas odpowiedzi: 16,308 sekund
W przykadzie tym wzitym z ycia optymalizator kosztowy
zdecydowa, e system Oracle powinien przeprowadzi przegld caej
tabeli (full table scan). Stao si tak dlatego, e optymalizator posiada
informacj o liczbie rnych wartoci, jakie przyjmowa mogy pola
w kolumnie STATUS, ale nie posiada informacji o liczbie rekordw
posiadajcych kad z tych wartoci. W konsekwencji optymalizator
zaoy rwnomierny rozkad danych (50/50) dla kadej z dwch war-
toci O oraz C. Przy takim zaoeniu system Oracle przeprowadza
przegld caej tabeli w celu pobrania danych o otwartych transakcjach.
System Oracle bdzie posiada informacj o asymetrii rozkadu da-
nych, czyli liczbie wierszy posiadajcych okrelon warto w zain-
deksowanych kolumnach, jeli podczas wykonywania polecenia ANA-
LYZE lub w momencie wywoywania pakietu DBMS_STATS poda si
opcj FOR ALL INDEXED COLUMNS. Zamy teraz, e kolumna
status posiada indeks. W celu zanalizowania tabeli uy naley na-
stpujcego polecenia:
ANALYZE TABLE TRANS COMPUTE STATISTICS
FOR ALL INDEXED COLUMNS
Po przeprowadzeniu analizy tabeli i obliczeniu statystyk dla wszystkich
zaindeksowanych kolumn, optymalizator kosztowy bdzie posiada in-
formacj o tym, e tylko w okoo 100 wierszach wystpuje warto O, co
sprawi, e w przypadku tej kolumny uyje indeksu. W rezultacie otrzy-
many zostanie duo krtszy czas odpowiedzi:
Czas odpowiedzi: 0,259 sekund
Zazwyczaj, optymalizator kosztowy przeprowadza przegld caej tabe-
li, jeli dana warto kolumny wystpuje w ponad 12% wierszy tabeli,
a korzysta z indeksu, gdy warto wystpuje w mniej ni 12% wierszy.
Wybr dokonywany przez optymalizator kosztowy nie opiera si na
tak prostej regule, jednak praktyka wskazuje, e jest to typowe jego
zachowanie.
Przed wprowadzeniem systemu Oracle9i jeli polecenie wykorzy-
stywao zmienne dowizane problem asymetrii wci mg wyst-
powa nawet wtedy, gdy uyto opcji FOR ALL INDEXED CO-
LUMNS. Warto przyjrze si nastpujcemu poleceniu:
local_status := 'O';
SELECT acct_no, customer, product, trans_date, amt
FROM trans
WHERE status = local_status;
Czas odpowiedzi: 16,608 sekund
Czas odpowiedzi jest zbliony do tego, ktry wystpowa w przypadku
nieuywania opcji FOR ALL INDEXED COLUMNS. Problem wyst-
puje dlatego, e optymalizator kosztowy nie zna wartoci zmiennej
dowizanej w momencie okrelania planu wykonania. Oglnie rzecz
biorc w celu uniknicia problemu asymetrii naley:
wartoci literaw zapisywa w kodzie bezporednio (na przy-
kad mona uy WHERE STATUS = 'O' zamiast WHERE
STATUS = local_status);
zawsze wykonywa analiz z opcj FOR ALL INDEXED
COLUMNS.
Jeli mimo to wci wystpuj problemy wydajnociowe zwizane
z nieuywaniem przez optymalizator kosztowy indeksu z powodu
zmiennych dowizanych, a nie ma moliwoci zmiany kodu rdowe-
go, pozostaje prba usunicia statystyk indeksu za pomoc polecenia:
ANALYZE INDEX
TRANS_STATUS_NDX
DELETE STATISTICS;
Usunicie statystyk indeksu poprawia sytuacj, gdy wymusza zacho-
wanie stosowane przez optymalizator reguowy, ktry zawsze korzysta
z istniejcych indeksw (zamiast przegldu caej tabeli).
79#)#
W systemie Oracle9i warto zmiennych dowizanych jest okrelana
przed podjciem decyzji o planie wykonania, co eliminuje koniecz-
no bezporedniego zapisywania w kodzie wartoci literaw.
2TQDNGOFTWIK
CPCNK\QYCPKGPKGQFRQYKGFPKEJFCP[EJ
Autor mia styczno z wieloma systemami, w ktrych problemy
z wydajnoci wynikay z tego, e tabele i indeksy nie byy analizowa-
ne w czasie, gdy zawieray typowe iloci danych. Optymalizator kosz-
towy musi posiada dokadne informacje (a w tym informacje o obj-
toci danych), aby mg okreli efektywny plan wykonania.
Sytuacje, w ktrych statystyki mog zosta utracone lub sta si nie-
aktualne, stanowi moe ponowne tworzenie tabeli lub jej przenosze-
nie, dodawanie indeksu lub tworzenie nowego rodowiska. Na przy-
kad administrator moe zapomnie o ponownym utworzeniu statystyk
po przeniesieniu schematu bazy danych do rodowiska produkcyjnego.
Problemy pojawiaj si take wtedy, gdy administrator nie posiada wy-
starczajcych informacji o bazie danych, ktr zarzdza i analizuje ta-
bel w momencie, gdy jest pusta, a nie wtedy, gdy po krtkim okresie
czasu ma ona setki lub tysice wierszy.
5RQUDURTCYF\GPKCFCV[QUVCVPKGLCPCNK\[
W celu sprawdzenia tego, ktre tabele, indeksy i partycje zostay prze-
analizowane i kiedy zostao to zrobione po raz ostatni, mona wykona
zapytanie pobierajce warto kolumny LAST_ANALYZED z rnych
perspektyw USER_XXX. Na przykad w celu okrelenia daty ostatniej
analizy wszystkich tabel naley wykona:
SELECT table_name, num_rows, last_analyzed
FROM user_tables;
Oprcz USER_TABLES istnieje wiele innych perspektyw, dziki kt-
rym mona sprawdzi dat analizy rnych obiektw. W celu otrzy-
mania penej listy perspektyw zawierajcych kolumn LAST_ANA-
LYZED naley wykona nastpujce zapytanie:
SELECT table_name
FROM all_tab_columns
WHERE column_name = 'LAST_ANALYZED';
Oczywicie nie chodzi o to, aby analizy z opcj COMPUTE przeprowa-
dza jak najczciej. Takie postpowanie moe spowodowa, e do-
strojone polecenie SQL ulegnie rozstrojeniu.
&GE[\LCQE\CUKGCPCNK\[
Ponowne analizowanie tabel i indeksw moe by rwnie niebezpiecz-
ne, jak dostosowywanie indeksw i w idealnej sytuacji powinno by
przeprowadzane na kopii bazy produkcyjnej przed ostatecznym wpro-
wadzeniem zmian w faktycznej bazie produkcyjnej.
Oprogramowanie firmy Peoplesoft jest przykadem aplikacji, ktra ko-
rzysta z tymczasowych tabel do przechowywania danych, ktrych na-
zwy kocz si wyraeniem _TMP. Kiedy rozpoczyna si wykonywa-
nie procesu wsadowego, kada z tych tabel jest zazwyczaj pusta.
W czasie wykonaniu kadego etapu procesu wsadowego na tabelach
wykonywane s operacje wstawiania i uaktualniania danych.
Ostatnia faza procesu polega na wstawieniu danych do gwnych tabel
obsugi transakcji aplikacji Poplesoft poprzez ekstrakcj danych z tabel
tymczasowych. Po zakoczeniu procesu wsadowego zwykle wszystkie
wiersze s z tabel tymczasowych usuwane. Transakcje zwizane z tymi
tabelami nie s zatwierdzone a do zakoczenia procesu, kiedy nie ma
ju w nich adnych danych.
Kiedy wydaje si polecenie ANALYZE wzgldem tabel tymczasowych,
zazwyczaj s one puste. Kiedy optymalizator kosztowy otrzymuje in-
formacj o zerowej liczbie wierszy, automatycznie podejmuje decyzj
o przegldzie caej tabeli oraz zastosowaniu zczenia kartezjaskiego.
W celu obejcia tego problemu Autor sugeruje zapenienie tabel tym-
czasowych danymi w celu przeprowadzenia analizy. Potem mona ta-
bele oprni z danych i rozpocz normalne przetwarzanie. Opr-
nienie tabel (polecenie TRUNCATE) nie powoduje usunicia statystyk.
Polecenia INSERT i UPDATE jzyka SQL uywane przez aplikacj
w celu wstawienia danych do tabel tymczasowych mona sprawdzi
stosujc procedur ledzenia (tracing) wzgldem procesu wsadowego,
ktry wstawia i uaktualnia dane. Tych samych polece SQL mona
uy do wasnorcznego zapenienia tabel danymi.
Przy zastosowaniu takiego ujcia problemu w jednym z duych orod-
kw w Australii, ktry korzysta z oprogramowania Peoplesoft, czas wy-
konania procesu wsadowego spad z 36 godzin do mniej ni 30 minut.
Jeli analizowanie tabel przechowujcych dane tymczasowe zawieraj-
ce produkcyjne iloci danych nie rozwizuje problemw wydajnocio-
wych, warto rozway usunicie statystyk odpowiednich dla tych tabel.
Wymusza to zastosowanie wzgldem polece SQL, ktre odwouj si
do tych tabel, zasad dziaania optymalizatora reguowego. Statystyki
mona usun korzystajc z polecenia ANALYZE nazwatab DE-
LETE STATISTICS. Po ich usuniciu wan spraw jest zapewnie-
nie tego, aby tabele te nie byy uywane w zczeniach z tabelami, kt-
re posiadaj statystyki. Naley take zapewni to, aby wzgldem
niezanalizowanych tabel nie byy uywane indeksy posiadajce staty-
styki. Jeli tabele tymczasowe s wykorzystywane oddzielnie i zcze-
nia wystpuj tylko pomidzy nimi samymi, wtedy preferowanym po-
dejciem jest czsto wykorzystanie zasad dziaania optymalizatora
reguowego.
2TQDNGOVT\GEKYURNPGW[YCPKG
QRV[OCNK\CVQTYRT\[\E\GPKCEJ
Jak wspomniano wczeniej, w sytuacji, gdy tabele podlegaj zczeniu
i jedna z nich zostanie zanalizowana, za pozostae tabele nie, optyma-
lizator kosztowy dziaa najmniej korzystnie.
Analizujc tabele oraz indeksy przy uyciu procedury DBMS_STATS.
GATHER_SCHEMA_STATS oraz procedury GATHER_TABLE_STATS
naley pamita o podaniu opcji CASCADE=>TRUE. Domylnie pakiet
DBMS_STATS zbiera statystyki jedynie dla tabel. Posiadanie statystyk
dla tabel, ale nie dla ich indeksw, take moe spowodowa obieranie
przez optymalizator kosztowy niewydajnych planw wykonania.
Jeden z przypadkw wystpienia takiego problemu, z jakim zetkn si
Autor, mia miejsce w systemie posiadajcym niezanalizowan tabel
trans oraz zanalizowan tabel acct. Administrator w celu usuni-
cia danych ponownie utworzy tabel trans, ale zapomnia wykona
analiz. Poniszy przykad ilustruje wydajno wykonania zczenia
obu tabel:
SELECT a.account_name, SUM(b.amount)
FROM trans b, acct a
WHERE b.trans_date > sysdate 7
AND a.act_id = b.acct_id
AND a.acct_status = 'A'
GROUP BY account_name;
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS FULL TRANS
Czas odpowiedzi: 410 sekund
Czas odpowiedzi uleg znacznemu skrceniu po zanalizowaniu tabeli
trans za pomoc poniszego polecenia:
ANALYZE TABLE trans ESTIMATE STATISTICS
SAMPLE 3 PERCENT
FOR ALL INDEXED COLUMNS
Nowy plan wykonania oraz czas odpowiedzi przedstawiay si nast-
pujco:
SORT GROUP BY
NESTED LOOPS
TABLE ACCESS BY ROWID ACCT
INDEX UNIQUE SCAN ACCT_PK
TABLE ACCESS BY ROWID TRANS
INDEX RANGE SCAN TRANS_NDX1
Czas odpowiedzi: 3,1 sekund
W innym systemie, ktry Autor take dostraja, twrca oprogramo-
wania zarzdzajcego informacjami kadrowymi zaleci analizowanie
tylko indeksw, a tabel nie. Dostawca oprogramowania opracowa
aplikacj dla systemu baz danych firmy Microsoft SQL Server
i przenis j do systemu Oracle. Rezultat analizowania samych in-
deksw mia daleko sigajcy negatywny wpyw na wydaj-
no. Na przykad:
SELECT COUNT(*)
FROM trans
WHERE acct_id = 9
AND cost_center = 'VIC';
TRANS_IDX2 jest na ACCT_ID
TRANS_NDX3 jest na COST_CENTER
Czas odpowiedzi: 77,3 sekund
Ironi losu byo to, e twrca oprogramowania obarcza win system
Oracle. Twierdzi bowiem, e jego wydajno jest nisza od systemu
SQL Server. Po zanalizowaniu tabel oraz indeksw czas odpowiedzi
polecenia SQL zosta drastycznie zmniejszony do 0,415 sekundy. Czas
odpowiedzi wielu innych polece SQL take znacznie si zmniejszy.
Mora pyncy z tej historii mgby brzmie: strojenie systemu Oracle
powinno by domen ekspertw systemu Oracle, za eksperci systemu
SQL Server powinni przy tym systemie pozosta. Jednake specjalici
z sektora IT coraz bardziej mobilni i pracujcy z wieloma systema-
mi baz danych powinni by moe po prostu z wiksz uwag czyta
podrczniki, kiedy przyjmuj na siebie obowizek strojenia nowej bazy
danych.
2TQDNGOE\YCTV[
Y[DKGTCPKGPKGQFRQYKGFPKGIQKPFGMUW
Optymalizator kosztowy wybiera czasem indeks podrzdny, nawet jeli
wydaje si spraw oczywist, e uyty by powinien inny indeks.
Warto przyjrze si nastpujcemu wyraeniu WHERE wystpujcemu
w oprogramowaniu Peoplesoft:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period = :8
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
System Peoplesoft, z ktrego pochodzi powyszy przykad, posiada
indeks zawierajcy wszystkie kolumny wyszczeglnione w wyraeniu
WHERE. Wydawa by si mogo, e system Oracle do wykonania za-
pytania uyje wanie tego indeksu. Jednak optymalizator kosztowy
zdecydowa o uyciu indeksu w kolumnach (business_unit,
ledger, fiscal_year, account). Po odtworzeniu polecenia
SQL i porwnaniu czasu wykonania z przypadkiem uycia wskazwki
nakazujcej wykorzystanie wikszego indeksu okazao si, e jest on
ponad czterokrotnie krtszy od czasu wykonania przy uyciu indeksu
wybranego przez optymalizator.
Dalsze badania wykazay, e indeks ten powinien by utworzony jako
unikatowy (UNIQUE), lecz w procesie usuwania danych i odtwarzania
tabeli omykowo utworzono go jako nieunikatowy. Oczywicie cztero-
krotny zysk czasu bardzo ucieszy uytkownika systemu.
Jednak pojawiy si inne problemy. Ten sam indeks by idealnym kan-
dydatem do wykorzystania w znajdujcym si poniej poleceniu, ktre
byo jednym z czciej wykonywanych w przypadku przetwarzania
danych na kocu miesica lub kocu roku:
where business_unit = :5
and ledger = :6
and fiscal_year = :7
and accounting_period between 1 and 12
and affiliate = :9
and statisctics_code = :10
and project_id = :11
and account = :12
and currency_cd = :13
and deptid = :14
and product = :15
Pomimo poprawnego utworzenia indeksu jako unikatowego, optymali-
zator kosztowy ponownie go nie wzi pod uwag. Jedyna rnica po-
midzy poleceniem biecym a poprzednim polegaa na tym, e doty-
czyo ono raczej zakresu okresw obrachunkowych (accounting
period) dla roku fiskalnego (fiscal year), a nie po prostu jednego okre-
su obrachunkowego.
Dla powyszego wyraenia WHERE uywany by ten sam, co poprzed-
nio, nieodpowiedni indeks z kolumnami (business_unit, ledger,
fiscal_year, account). I ponownie po zmierzeniu czasu wyko-
nania polecenia przy uyciu indeksu wybranego przez optymalizator
kosztowy oraz indeksu zawierajcego wszystkie kolumny okazao si,
e ten drugi zapewnia co najmniej trzykrotnie szybsze wykonanie.
Problem rozwizano dziki przestawieniu kolumny accounting_
period na ostatni pozycj w indeksie (oryginalnie znajdowaa si na
trzeciej). Nowy indeks mia nastpujc posta:
business_unit
ledger
fiscal_year
affiliate
statisctics_code
project_id
account
currency_cd
deptid
product
accounting_period
Innym sposobem zmuszenia optymalizatora kosztowego do uycia dane-
go indeksu jest wykorzystanie jednej ze wskazwek, ktre pozwalaj na
jego okrelenie. Jest to dobre rozwizanie, jednak wiele orodkw korzy-
sta z pakietw dostarczanych przez twrcw oprogramowania, ktrych
nie mona modyfikowa (a w konsekwencji nie mona wykorzysta
wskazwek). Jednak moliwe jest utworzenie perspektywy zawierajcej
wskazwk oraz nadanie uytkownikom uprawnie dostpu do tej per-
spektywy. Bdzie ona przydatna, jeli polecenie SQL, ktrego wydaj-
no wykonania pozostawia wiele do yczenia, stanowi cz raportu lub
zapytania bezporedniego, ktre mog odczytywa perspektyw.
W ostatecznoci okazuje si czasem, e mona wymusi uycie in-
deksu, jeli usunie si jego statystyki. Czasem mona take uy po-
lecenia ANALYZE ESTIMATE z jedynie podstawow wartoci
1064 analizowanych wierszy. Czsto zdarza si, e plan wykonania
zmieniony zostanie na podany, jednak ten rodzaj postpowania ma
w sobie co z czarowania. Niezmiernie istotn spraw jest to, aby
stosujc takie magiczne dziaania dokadnie udokumentowa wy-
konane czynnoci. Jeszcze inna metoda polega na prbie zmniejsze-
nia parametru OPTIMIZER_INDEX_COST_ADJ
*
do wartoci z prze-
dziau 10 do 50.
Podsumowujc trzeba odpowiedzie na pytanie o to, dlaczego optyma-
lizator kosztowy podejmuje takie nieodpowiednie decyzje. Po pierwsze
naley podkreli, e za decyzja dotyczca planu wykonania to ra-
czej wyjtek ni regua. Przykady z niniejszego podrozdziau pokazu-
j, e kolumny s rozpatrywane raczej indywidualnie ni grupowo.
Gdyby tak byo, w pierwszym z prezentowanych przykadw optyma-
___________________________
*
Warto tego parametru ustawia si w pliku INIT.ORA przyp. tum
lizator kosztowy stwierdziby bez koniecznoci odtworzenia indek-
su przez administratora jako unikatowego e kady wiersz posiada
unikatowe wartoci. Przykad drugi pokazuje, e jeli kilka kolumn
indeksu posiada ma liczb rnych dopuszczalnych wartoci, a pole-
cenie SQL da dostpu do wikszoci z nich, to optymalizator kosz-
towy czsto pomija taki indeks. Dzieje si tak, mimo e rozpatrywane
razem kolumny s cile okrelone i zapytanie zwrci niewiele wierszy.
Nieco usprawiedliwiajc dziaanie optymalizatora naley stwierdzi, e
uycie indeksw o mniejszej iloci kolumn czsto daje znaczny wzrost
wydajnoci wykonywania w porwnaniu z uyciem indeksw o wielu
kolumnach.
2TQDNGORKV[\E\CPKG\D[VYKGNWVCDGN
Pierwsze wersje optymalizatora kosztowego czsto wykorzystyway
metod dziel i rzd w sytuacji, gdy zczaniu podlegao wicej ni
pi tabel. Rozpatrzmy przykad przedstawiony na rysunku 1. Zapyta-
nie wybiera wszystkie dane zwizane z przedsibiorstwem o identyfi-
katorze rachunku (kolumna acct_id) rwnym 777818. Przedsibior-
stwo posiada kilka oddziaw, a zapytanie dotyczy oddziau znajdujcego
si w stanie Waszyngton (WA). Tabela A to tabela acct, tabela F to
acct_address, za tabela G to address.
Rysunek 1. Zczenie siedmiu tabel
Uytkownik oczekuje, e zapytanie zwrci stosunkowo niedu liczb
wierszy z rnych tabel, a czas odpowiedzi nie bdzie przekracza 1 se-
kundy. Najlepiej jest, jeli system Oracle otrzymuje wiersze z tabeli
acct_address odpowiadajce danemu rachunkowi, a nastpnie z-
cza j z tabel address w celu okrelenia tego, czy adresy odpowiadaj
stanowi Waszyngton.
Jednake ze wzgldu na to, e zczeniu podlega tak wiele tabel, opty-
malizator kosztowy czsto decydowa bdzie o tym, e przetwarzane
bd tabele F i G niezalenie od pozostaych i dopiero na kocu dane
zostan scalone. Rezultatem zczenia tabel F i G bdzie to, e bd
musiay zosta wybrane wszystkie adresy, ktre dotycz stanu Wa-
szyngton. Proces ten moe zaj nawet kilka minut, co zapewne spo-
woduje, e oglny czas wykonania bdzie duo duszy od tego, ktry
miaby miejsce, gdyby system Oracle sterowa dostpem do wszyst-
kich tabel od tabeli A.
Zakadajc, e tabela acct_address (F) posiada indeks w kolumnie
acct_id, mona problem ten rozwiza wykorzystujc odpowiedni
wskazwk instruujc optymalizator kosztowy, e uyty powinien
zosta ten wanie indeks. Znacznie zwikszy to wydajno.
Co interesujce optymalizator reguowy ma czsto duo wiksze
problemy z poprawnym okreleniem planu wykonania w przypadku
zczania wielu tabel ni optymalizator kosztowy. Optymalizator re-
guowy czsto w ogle nie uywa tabeli acct jako tabeli sterujcej.
Aby to wymusi, naley w wyraeniu FROM nazw tabeli A umieci
jako ostatni.
Jeli wykorzystywane jest gotowe oprogramowanie, najlepszym spo-
sobem moe by utworzenie perspektywy zawierajcej wskazwk
(o ile jest to dopuszczalne i moliwe w przypadku uywanego pakietu).
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
PRZYKADOWY ROZDZIA PRZYKADOWY ROZDZIA
IDZ DO IDZ DO
ZAMW DRUKOWANY KATALOG ZAMW DRUKOWANY KATALOG
KATALOG KSIEK KATALOG KSIEK
TWJ KOSZYK TWJ KOSZYK
CENNIK I INFORMACJE CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK ZAMW CENNIK
CZYTELNIA CZYTELNIA
FRAGMENTY KSIEK ONLINE FRAGMENTY KSIEK ONLINE
SPIS TRECI SPIS TRECI
DODAJ DO KOSZYKA DODAJ DO KOSZYKA
KATALOG ONLINE KATALOG ONLINE
Optymalizacja Oracle SQL.
Leksykon kieszonkowy
Autor: Mark Gurry
Tumaczenie: Bartomiej Garbacz
ISBN: 83-7197-983-5
Tytu oryginau: Oracle SQL Tuning. Pocket Reference
Format: B5, stron: 128
Niezoptymalizowane polecenia SQL s jednym z gwnych czynnikw powodujcych
mao wydajne dziaanie systemu bazy danych. W niniejszej ksice Mark Gurry dzieli
si z Czytelnikiem swoimi przemyleniami dotyczcymi problemu optymalizacji. Autor
prezentuje rozwizania wielu typowych problemw za pomoc wbudowanych
w Oracle'a optymalizatorw. Omawia midzy innymi:
Problem wyboru optymalizatora
Dziaanie optymalizatora reguowego (rule-based)
Dziaanie optymalizatora kosztowego (cost-based)
Problemy wsplne dla obu optymalizatorw
Optymalizacja Oracle SQL. Leksykon kieszonkowy zaoszczdzi wiele czasu
powiconego na pisanie wydajnych zapyta. Powinna si znale w biblioteczce
kadego administratora i uytkownika Oracle'a.
5RKUVTGEK
Wstp....................................................................................... 5
Optymalizatory SQI .............................................................. 9
Dziaanie optymalizatora reguowego..................................................10
Dziaanie optymalizatora kosztowego .................................................17
Czste nieporozumienia zwizane z optymalizatorami .......................25
Wybr optymalizatora..........................................................................26
Problemy i ich rozuizania
u przypadku optymalizatora reguouego ............................ 27
Problem pierwszy: nieodpowiednia tabela sterujca ...........................28
Problem drugi: nieodpowiedni indeks .................................................29
Problem trzeci: nieodpowiedni indeks sterujcy..................................30
Problem czwarty: uycie indeksu ORDER BY
zamiast indeksu WHERE.....................................................................32
Problemy i ich rozuizania
u przypadku optymalizatora kosztouego ............................ 33
Problem pierwszy: problem asymetrii .................................................33
Problem drugi: analizowanie nieodpowiednich danych.......................36
Problem trzeci: wsplne uywanie optymalizatorw przy zczeniach ..38
Problem czwarty: wybieranie nieodpowiedniego indeksu...................41
Problem pity: zczanie zbyt wielu tabel............................................44
Problem szsty: nieodpowiednie ustawienia parametrw
w pliku INIT.ORA...............................................................................45
Problemy usplne
dla optymalizatora reguouego i kosztouego....................... 51
Problem pierwszy: polecenia zapisane
w postaci uniemoliwiajcej wykorzystanie indeksw........................52
Problem drugi: brak indeksw lub nieodpowiednie indeksy ...............56