Úvod do optimalizace v Oracle 9i

Jaroslav Tykal, Jiří Dokulil

Optimalizátor

určuje způsob vyhodnocení každého SQL dotazu

kvalita určuje i efektivitu zpracování

pro uživatele plně transparentní obvykle „cost-based“ (první

implementace v Oracle 7 – 1992)

Části optimalizátoru Transformace SQL Výběr exekučního plánu Výběr zpracování dle statistik a

ceny operace Optimalizace za běhu

Optimalizace na základě pravidel

Transformace SQL Cíl:

vytvořit k původnímu SQL dotazu dotaz sémanticky ekvivalentní, který půjde efektivněji zpracovat

Typy transformací: heuristické cost-based – výběr nejlepší z

propočítaných strategií

Heuristické transformace vlastnosti:

aplikují se kdykoliv je to možné výstup vždy stejný nebo lepší nesnižuje výkon databáze

typy: úprava pohledů („view merging“) „zploštění“ dotazů generování tranzitivních predikátů eliminace společných podvýrazů predikáty pushdown a pullup, CUBE, …

Jednoduché pohledy

Definujeme: CREATE VIEW TEST_VIEW AS SELECT ENAME,

DNAME, SAL FROM EMP E, DEPT D WHERE E.DEPTNO = D.DEPTNO

Dotaz: SELECT ENAME, DNAME FROM TEST_VIEW WHERE

SAL > 10000 Po transformaci:

SELECT ENAME, DNAME FROM EMP E, DEPT D WHERE D.DEPTNO = E.DEPTNO AND E.SAL > 10000

Složitější pohledy (s agreg. funkcí)

Definujeme: CREATE VIEW AVG_SAL_VIEW AS

SELECT DEPTNO, AVG(SAL) AVG_SAL_DEPT FROM EMP GROUP BY DEPTNO

Požadujeme: SELECT DEPT.NAME, AVG_SAL_DEPT FROM DEPT,

AVG_SAL_VIEW WHERE DEPT.DEPTNO = AVG_SAL_VIEW.DEPTNO AND DEPT.LOC = ‘OAKLAND’

Po transformaci: SELECT DEPT.NAME, AVG(SAL) FROM DEPT, EMP WHERE

DEPT.DEPTNO=EMP.DEPTNO AND DEPT.LOC = ‘OAKLAND’ GROUP BY DEPT.ROWID, DEPT.NAME

Subquery „flattening“ převod mnoha typů dotazů pomocí join,

semi-join nebo anti-join příklad:

SELECT D.DNAME FROM DEPT D WHERE

D.DEPTNO IN

(SELECT E.DEPTNO FROM EMP E WHERE E.SAL > 10000)

mnoho způsobů jak vyhodnotit zvážení možných transformací a výběr

nejlepší na základě ceny

Exekuční plán (1)

bez transformací tabulka EMP se prochází pro každý záznam v DEPT velká složitost

Operace Objekt Volba

SELECT STATEMENT

FILTER

TABLE ACCESS DEPT FULL

TABLE ACCESS EMP FULL

Exekuční plán (2)

lepší plán pomocí semi join, který eliminuje duplicitní hodnoty z vnitřní tabulky

v tomto případě zvoleno hash semi join Oracle nabízí také sort-merge semi join a nested-loop semi

join Po transformaci (pseudo SQL):

SELECT DNAME FROM EMP E, DEPT D WHERE D.DEPTNO <semijoin> E.DEPTNO AND E.SAL > 10000

Operace Objekt Volba

SELECT STATEMENT

HASH JOIN SEMI

TABLE ACCESS DEPT FULL

TABLE ACCESS EMP FULL

Exekuční plán (3)

unique sort eliminuje duplicitni položky DEPTNO v tabulce EMP

Po transformaci: SELECT D.DNAME

FROM (SELECT DISTINCT DEPTNO FROM EMP) E, DEPT D WHERE E.DEPTNO = D.DEPTNO AND E.SAL > 10000

Operace Objekt Volba

SELECT STATEMENT

HASH JOIN

SORT UNIQUE

TABLE ACCESS EMP FULL

TABLE ACCESS DEPT FULL

Generování tranzitivního predikátu

Př: počet položek, které byly doručeny v den objednání

SELECT COUNT(DISTINCT O_ORDERKEY) FROM ORDER, LINEITEM WHERE O_ORDERKEY = L_ORDERKEY AND O_ORDERDATE = L_SHIPDATE AND O_ORDERDATE BETWEEN ‘1-JAN-2002’ AND ’31-JAN-2002’

Po transformaci (přidání dodatečného predikátu) SELECT COUNT(DISTINCT O_ORDERKEY) FROM ORDER, LINEITEM

WHERE O_ORDERKEY = L_ORDERKEY AND O_ORDERDATE = L_SHIPDATEAND O_ORDERDATE BETWEEN ‘1-JAN-2002’ AND ’31-JAN-2002’ AND L_SHIPDATE BETWEEN ‘1-JAN-2002’ AND ’31-JAN-2002’

Eliminace opakujicích se podvýrazů

Př: zaměstnance v Dallasu, kteří jsou víceprezident nebo mají plat vyšší než 100 000

SELECT * FROM EMP, DEPT WHERE(EMP.DEPTNO = DEPT.DEPTNO AND LOC=‘Dallas’ AND SAL > 100000)OR(EMP.DEPTNO = DEPT.DEPTNO AND LOC=‘Dallas’ AND JOB_TITLE=‘VICE PRESIDENT’)

Po transformaci: SELECT * FROM EMP, DEPT WHERE

EMP.DEPTNO = DEPT.DEPTNO AND LOC=‘Dallas’ AND (SAL > 100000 OR JOB_TITLE=‘VICE PRESIDENT’)

Operátory pushup, pulldown

dotaz může obsahovat více pohledů a poddotazů s mnoha podmínkami

Oracle může tyto podmínky přesunovat dovnitř, ven nebo mezi jednotlivými pohledy a poddotazy

důsledky: data pro GROUP BY nebo JOIN bývají menší lze použít jiné metody pro vyhodnocení (access

path), které nejsou možné před úpravou

Operátory pushup, pulldown

Příklad pushdown Zadáno

CREATE VIEW EMP_AGG AS SELECT DEPTNO, AVG(SAL) AVG_SAL FROM EMP GROUP BY DEPTNO

Dotaz SELECT DEPTNO, AVG_SAL FROM EMP_AGG WHERE DEPTNO =

10

Po transformaci SELECT DEPTNO, AVG(SAL) FROM EMP

WHERE DEPTNO = 10 GROUP BY DEPTNO

Prořezání dotazu s „CUBE“ (1)

CUBE – rozšíření SQL operátoru GROUP BY, které umožňuje více agragací v jednom SQL dotazu

transformací některých dotazů lze docílit významného ořezání dat pro agregační funkci

dotazy pocházejí obvykle od analytických nástrojů (aplikací), které používají předdefinovaný základ „cube“

Prořezání dotazu s „CUBE“ (2)

Původní dotaz SELECT MONTH, REGION, DEPARTMENT, REVENUE FROM

(SELECT MONTH, REGION, DEPARTMENT, SUM(SALES_AMOUNT) AS REVENUE FROM SALES GROUP BY CUBE (MONTH, REGION, DEPT)) WHERE MONTH = ‘JAN-2001’

Transformovaný dotaz SELECT MONTH, REGION, DEPARTMENT, REVENUE FROM

(SELECT MONTH, REGION, DEPARTMENT, SUM(SALES_AMOUNT) AS REVENUE FROM SALES WHERE MONTH = ‘JAN-2001’ GROUP BY MONTH, CUBE (REGION, DEPT)) WHERE MONTH = ‘JAN-2001’

Konverze vnějšího spojení

provádí se v případě, kdy vnější spojení dává stejný výsledek jako spojení vnitřní

konverze na vnitřní spojení může umožnit další optimalizace, které nejsou na vnějším spojení možná

spojování pohledů („view merging“) změnu pořadí spojování

Cost-based transformace vlastnosti:

používají se pro mnoho typů transformací transformovaný dotaz je porovnán s

původním dotazem a podle předpokládané složitosti (ceny) vyhodnocení, je vybrán nejlepší

typy: použití materializovaných pohledů OR „rozšíření“ transformace „hvězdy“ predikát pushdown pro vnější spojení pohledů

Materializované pohledy vlastnosti:

bývají menší mohou obsahovat předpočítané hodnoty (vyhodnocené

agregační funkce) transformace:

spočívá v nahrazování čtení z několika tabulek čtením z materializovaných pohledů

může výrazně urychlit vyhodnocení dotazu nemusí být vždy urychlením (př.: základní tabulka je

vhodně indexovaná, m.p. ne) další implementované optimalizace:

provázání hierarchie dimenze u uložení dat ve formátu „Hvězdy“ (data warehouse)

Materializované pohledy (příklad)

Máme materializovaný pohled CREATE MATERIALIZED VIEW SALES_SUMMARY AS

SELECT SALES.CUST_ID, TIME.MONTH, SUM(SALES_AMOUNT) AMT

FROM SALES, TIME

WHERE SALES.TIME_ID = TIME.TIME_ID

Dotaz SELECT CUSTOMER.CUST_NAME, TIME.MONTH, SUM(SALES.SALES_AMOUNT)

FROM SALES, CUSTOMER, TIME

WHERE SALES.CUST_ID = CUST.CUST_ID AND SALES.TIME_ID = TIME.TIME_ID

GROUP BY CUSTOMER.CUST_NAME, TIME.MONTH

Po přepsání SELECT CUSTOMER.CUST_NAME, SALES_SUMMARY.MONTH,

SALES_SUMMARY.AMT

FROM CUSTOMER, SALES_SUMMARY

WHERE CUSTOMER.CUST_ID = SALES_SUMMARY.CUST_ID

Rozšíření dotazu - OR Přepis OR v části WHERE pomocí konstrukce SELECT …

UNION SELECT … bez použití OR pro každou takovou podmínku

Dotaz SELECT * FROM SHIPMENT, PORT P1, PORT P2

WHERE SHIPMENT.SOURCE_PORT_ID = P1.PORT_ID AND SHIPMENT.DESTINATION_PORT_ID = P2.PORT_ID AND (P1.PORT_NAME = ‘OAKLAND’ OR P2.PORT_NAME = ‘OAKLAND’)

Po transformaci SELECT * FROM SHIPMENT, PORT P1, PORT P2

WHERE SHIPMENT.SOURCE_PORT_ID = P1.PORT_ID AND SHIPMENT.DESTINATION_PORT_ID = P2.PORT_ID AND P1.PORT_NAME = ‘OAKLAND’

UNIONSELECT * FROM SHIPMENT, PORT P1, PORT P2 WHERE SHIPMENT.SOURCE_PORT_ID = P1.PORT_ID

AND SHIPMENT.DESTINATION_PORT_ID = P2.PORT_ID AND P2.PORT_NAME <> ‘OAKLAND’ AND P1.PORT_NAME <> ‘OAKLAND’

Schema hvězdy strategie uchovávání dat používaná v oblasti

datových skladů typicky obsahuje jednu nebo více obsáhlých

tabulek (tabulek faktů) a mnoho menších tabulek (tabulky dimenzí) – obsahují popisná data

Oracle podporuje techniku vyhodnocování dotazů nazývanou „star transformation“

funguje na principu vkládání poddotazů do položeného dotazu

vložené dotazy a bitmapové indexy umožňují efektivnější přístup k datům v tabulce faktů

Schema hvězdy - příklad Datové schema příkladu

Tabulka faktů

Dimenze času2 úrovně: den,

čtvrtletí

Schema hvězdy - příklad Před transformací

SELECT STORE.STATE, SUM(S.AMOUNT) FROM SALES S, DAY D, QUARTER Q, PRODUCT P, STORE WHERE S.DAY_ID = D.DAY_ID AND D.QUARTER_ID = Q.QUARTER_ID

AND S.PRODUCT_ID = P.PRODUCT_ID AND S.STORE_ID = S.STORE_ID AND P.PRODUCT_CATEGORY = ‘BEVERAGES’ AND Q.QUARTER_NAME =

‘2001Q3’ GROUP BY STORE.STATE

Po transformaciSELECT STORE.STATE, SUM(SALES.AMOUNT) FROM SALES, STORE WHERE SALES.STORE_ID = STORE.STORE_ID

AND SALES.DAY_ID IN (SELECT DAY.DAY_ID FROM DAY D, QUARTER Q WHERE

D.QUARTER_ID = Q.QUARTER_ID AND Q.QUARTER_NAME = ‘2001Q3’) AND SALES.PRODUCT_ID IN (SELECT PRODUCT.PRODUCT_ID FROM PRODUCT WHERE

PRODUCT.PRODUCT_CATEGORY = ‘BEVERAGES’) GROUP BY STORE.STATE

Schema hvězdy Transformované SQL je zpracováno ve

dvou částech potřebné řádky z tabulky faktů jsou vybrány

pomocí bitmap indexu (v tomto případě se přistupuje pomocí DAY_ID a PRODUCT_ID, které jsou nalezeny pomocí poddotazů

na nalezené řádky je proveden join s tabulkou STORE

tento postup je patentovaný Oracle

Pushdown pro vnější spojení při použití vnějšího spojení nelze přehodit

pořadí spojovaných tabulek

Oracle používá operátor Pushdown, který přesune podmínku do jedné ze spojovaných tabulek

vnější spojení pak lze urychlit za použití indexů

ne vždy musí být rychlejší než původní spojení

Část 2 – určení pořadí spojení

Access path selection

Předpoklady velké množství datových struktur tabulky

běžné tabulky tabulky organizované jako index hnízděné tabulky klastrované tabulky …

indexy B-stromy bitmapové indexy bitmapové spojovací indexy (bitmap join indexes) B-stromy indexující podle funkce bitmapové indexy indexující podle funkce doménové indexy

Předpoklady 2

existuje velké množství (14) různých metod práce s indexy

přímo operace spojení má také přes deset verzí

Trocha počtů Při 5 tabulkách existuje 5!=120 různých pořadí

spojení tabulek pro každé spojení existuje mnoho různých

plánů, používajících různé kombinace indexů, přístupových metod a metod spojování

celkem pro 5 tabulek existuje několik tisíc plánů, což je dostatečně malé množství, aby bylo možné uvážit všechny

pro 10 tabulek už však dostaneme přes 3,5 milionů možných pořadí a hodně přes 100 milionů možných plánů

hrubá síla tedy není řešením

Jak moc je třeba optimalizovat? Oracle používá adaptivní vyhledávací

strategii, která má zajistit to, že doba strávená hledáním optimálního řešení nepřesáhne zlomek doby potřebné na vyhodnocení

pokud bude dotaz trvat 1 vteřinu, nemá smysl jej 10 vteřin optimalizovat

pokud dotaz pravděpodobně poběží několik hodin, je vhodné věnovat několik vteřin nebo i minut na nalezení lepšího plánu

Heuristiky

na začátku tvorby exekučního plánu je před samotným prohledáváním prostoru plánů použito několik heuristik, které mají šanci najít optimální -nebo alespoň dostatečně dobrý- plán okamžitě

není velkým překvapením, že Oracle o nich nic podrobnějšího neprozradí

Bitmapové indexy dva typy

„pravé“ – komprimované bitové mapy uložené v databázi

dynamické – B-stromy, které jsou za běhu převedeny na bitové mapy

uložení bitmapového indexu může vést k až desetinásobné úspoře místa, což vede díky menšímu počtu I/O operací k až desetinásobnému nárůstu výkonu

velká síla těchto indexů je ve vyhodnocování podmínek propojených pomocí AND, OR a NOT

Bitmapové indexy 2 dynamické bitmapové indexy při práci

využívají hešování a vyžadují přístup k tabulce přes její rowid, aby dávaly správné výsledky

„skutečné“ bitmapové indexy jsou schopné vrátit přesný výsledek pouze zpracováním indexu SELECT COUNT(*) FROM ZÁKAZNÍCI

WHERE stát=‘ČR’ AND stav=‘svobodný’ pokud pro tento dotaz existují bitmapové

indexy nad stát a stav, pak je možné získat výsledek provedením AND na tyto indexy a spočítáním jedniček

Bitmapové indexy 3

Oracle umožňuje použít více různých typů indexů pro přistup k jedné tabulce

při použití bitmapového a jiného indexu (např. B-strom) je druhý index převeden na dynamický bitmapový

Bitmapové spojovací indexy (bitmap join indexes) tyto indexy slouží ke zrychlení konkrétních spojení součástí jejich definice je, které tabulky a přes

jakou podmínku budou spojovány klasický přiklad použití je pro spojení faktové a

dimensionální tabulky v datovém skladu. Například pro fakta o prodeji a dimenzi produkt je možné vytvořit index nad prodeji spojenými přes cizí klíč na produkt, ale jako indexovaný sloupec určit kategorii produktu. Takový index pak umožní najít prodeje produktů z určité kategorie bez nutnosti skutečně provést spojení těchto tabulek

Bitmapové spojovací indexy (bitmap join indexes) takto vytvořený index bude navíc

menší počet kategorií produktů bude jistě

meňší než počet produktů menší kardinalita u bitmapového indexu

znamená jeho menší velikost tyto indexy je možné kombinovat s

indexy nad tabulkami a jejich kombinace bude jako kombinace běžných bitmapových indexů

Aplikační doménové indexy Oracle podporuje aplikační doménové

indexy, což jsou uživatelské struktury, které umožňují efektivní přitup k datům jako dokumenty, obrázky a video.

těmto indexům je možné přiřadit statistiky a cenové funkce

optimalizátor pak dokáže tyto indexy používat ve optimalizacích stejně jako vestavěné indexy

Sekvenční přístup k indexu

Oracle dokáže projít index jako tabulku, tedy nikoliv jako strom, ale sekvenčně

pokud chceme z tabulky vybrat jen sloupce, které jsou všechny obsaženy v indexu, a jsme nuceni projít je celá

index bude pravděpodobně menší než tabulka, takže ušetříme I/O operace

Spojení dat z více indexů pokud existuje několik indexů, které

dohromady obsahují všechna data potřebná pro dotaz

podmínka WHERE je použita na tyto indexy a každý vrátí množinu záznamů

tyto množiny jsou spojeny na základě jejich rowid

má význam, pokud podkladová tabulka má hodně sloupců, ale potřebných je jen několik málo

Využití indexu bez podmínky na první sloupec může se stát, že v podmínce dotazu není žádné

omezení na hodnoty v prvním sloupci indexu přesto může mít použití tohoto indexy smysl,

pokud existují podmínky na dalších sloupcích a počet různých hodnot v prvním sloupci indexu je omezený

pak je možné pro každou hodnotu prvního sloupce zkusit použít podmínku na další sloupce

může se hodit, pokud neexistuje žádný přesně vyhovující index a jediná alternativa je sekvenční průchod tabulkou nebo indexem

Eliminace třídění třídění velkých dat je náročné důvodů pro třídění je více

ORDER BY GROUP BY DISTINCT

často je možné se vyhnout tomu, že data jsou skutečně tříděna

přístup podle indexu zajistí automaticky setřídění existence UNIQUE omezení odstraní nutnost třídění

kvůli distinct nenáročné utřídění malých dat někde na počátku

vyhodnocení může zajistit požadované utřídění celých dat

…

Eliminace třídění 2 celkově je tento problém řešen tvorbou

dvou plánů vyhodnocení obvyklý plán na základě lokálních optimalizací plán, který je zaměřen právě na využití

přístupů pro eliminaci třídění pro oba plány je nakonec spočítána

celková cena často se plán eliminující třídění ukáže jako

lepší

Paralelizmus

jeden dotaz je možné pustit na více procesorech nebo dokonce na více uzlech

stupeň paralelismu je téměř neomezený

…a víc toho Oracle neprozradí

Hints – nápovědy optimalizátor není dokonalý, mlže vytvořit

suboptimální plán použití by mělo být řídké vhodné pro řešení otázek jako

Má smysl udržovat v databázi tento index? údržba indexů něco stojí pokud je index používán jen v jednom dotazu, je možné

jej zrušit bez velké ztráty výkonu v tomto dotaze pomocí nápovědy je možné tento experiment snadno

provést, bez smazání a nového postavení indexu v době jejich vytvoření mlže být vhodné, ale

při nárůstu velikosti tabulky nebo jiné změně situace už může být plán poskytnutý optimalizátorem lepší

Určení ceny dotazu přesnost určení ceny dotazu zásadně ovlivňuje

efektivnost optimalizátoru vychází ze

znalosti principu všech používaných přístupových metod statistik o objektech v databázi statistik o výkonu použitého HW vliv různých optimalizací

různé cache optimalizace I/O operací paralelizmus …

cíle optimalizace podle nastavení administrátora se optimalizuje

doba na vrácení prvního řádku doba na vrácení prvních N řádků doba na vrácení prvních celého výsledku

Statistiky – objekty v databázi

počet bloků a řádek v tabulce počet úrovní v B-stromu u indexu statistiky pro každý sloupce

slouží pro odhad výsledku podmínky WHERE

minimální hodnota maximální hodnota počet různých hodnot histogramy

Statistiky – systém

výkon HW výkon CPU výkon v I/O operacích

kombinace těchto hledisek není na základě pevného vzorce, ale pozorovaného chování systému za běžné zátěže

Statistiky – uživatelské

pro uživatelem definované funkce a doménové indexy

optimalizátor je na to připravený a díky tomu dokáže pracovat s uživatelskými funkcemi a indexy stejně jako s vlastními

Správa statistik vytváření statistik je náročné

nevytvářejí se z celé tabulky, ale jen ze vzorku dat

vytvářejí se paralelně jak poznat, že je potřeba přepočítat

statistiky Oracle sleduje počet insert, update a delete a

přepočítává statistiky jen výrazně změněných tabulek

určení sloupců, pro které se vyplatí udělat histgram sleduje se

rozložení hodnot ve sloupci četnost výskytu sloupce ve WHERE

Dynamické vzorkování statistiky v určitých případech nevyhovují

tabulky, které pouze obsahují mezivýpočty v nich mimo výpočet nejsou data, takže během sběru

statistik se nic nezjistí závislé sloupce

běžné statistiky vycházejí z předpokladu, že sloupce jsou nezávislé. To samozřejmě často není pravda

pokud Oracle usoudí, že nastala některá z těchto situací, tak během optimalizace otestuje malý vzorek dat

pokud jde o možnou závislost sloupců, pak je na všechny relevantní sloupce použita podmínka WHERE a podle výsledku je usouzeno, jestli mezi sloupci je nějaký vztah.

Část 4 – Dynamická optimalizace

Dynamic Runtime Optimization

Proč zátěž na databázi je proměnlivá

přes den/v noci, v průběhu měsíce/na konci měsíce, …

uvedené optimalizace (SQL transformace, access path) jsou zaměřeny na optimalizaci jednoho dotazu

je třeba provádět optimalizace na úrovni databáze

Je třeba sdílet některé zdroje CPU Paměť

Hlavní části dynamické optimalizace

stupeň paralelismu

alokace paměti

správa zdrojů

Stupeň paralelismu

dobrý způsob pro zvýšení výkonu na víceprocesorovém systému

s vyšším stupněm paralelismu jsou i vyšší nároky na zdroje než při použití sekvenčního spouštění dotazů

vysoký stupeň paralelismu může být na velmi vytížených systémech kontraproduktivní

při nízkém vytížení je možné používat vyšší stupeň je vhodné mít proměnlivý stupeň paralelismu

na systémech s proměnlivým zatížením Oracle automaticky přizpůsobuje stupeň na základě

vytížení zdrojů

Jak přidělovat paměť

některé operace (hash, join, sort, …) používají opakované čtení dat

jsou rychlejší, pokud se provádějí v paměti omezené množství paměti

swapování – rychlý pokles výkonu cíl:

dotazy, které jsou náročné na paměť, dostanou více nemohou dostat tolik, aby znemožnily práci ostatním

dotazy, které nejsou náročné, dostanou méně

Jak přidělovat paměť

pevná velikost přidělené paměti při růstu požadavků je třeba více a více paměti –

může dojít k odkládání na disk => snižování výkonu některé dotazy potřebují více, jiné méně –

neodpovídá potřebám pevný podíl pro každý dotaz (100 dotazů,

každý dostane 1% paměti) nemusí odpovídat potřebám jednotlivých dotazů –

jeden má přebytek paměti, druhý nedostatek např. kvůli použití operace sort, join, …

Dynamická alokace paměti

Dynamická správa paměti

hlídá množství přidělené paměti pro zpracování dotazů určení náročnosti zpracování dotazu

požadavky jsou odhadnuty při hledání nejlepšího exekučního plánu požadavky se berou v úvahu při volbě nejlepšího exekučního plánu

jak přesně probíhá přidělování/odebírání si volí databáze dle nastaveného profilu správy paměti

přiděluje paměť pro zpracování dotazu na základě odhadu exekučního plánu, vytížení a volných prostředků pokud se zjistí, že výpočet urychlí více paměti a paměť je dostupná

odebírá paměť zpracování dotazu pokud výpočet nepotřebuje celou přidělenou paměť, je mu část

odebrána

Manažer prostředků

spravuje prostředky všech uživatelů kontroluje spouštění dotazů

množství CPU, které je přiděleno určité skupině uživatelů počet aktivních připojení pro skupinu uživatelů hlídá, která skupina uživatelů může používat paralelní zpracování

hlavní cíle: maximalizuje propustnost celého systému poskytuje zdroje správným uživatelům

někteří uživatelé mohou mít vyšší prioritu někteří uživatelé mohou mít právo k více zdrojům

propustnost: náročný dotaz je spuštěn s nižší prioritou, aby nezahltil celou DB možnost definice doby nejdelšího spuštění dotazu – pro aktivní

opatření

Závěr

zdroj: Query Optimization in Oracle9i, An Oracle White Paper, February 2002, http://www.oracle.com/technology/products/bi/pdf/o9i_optimization_twp.pdf