Use EXPLAIN PLAN and TKPROF to Tune Your Applications

Végrehajtási terv és TKPROFa hatákonyság növelésére

Roger Schrag

Database Specialists, Inc.

www.dbspecialists.com

A mai előadás

VÉGREHAJTÁSI TERV áttekintés

TKPROF áttekintés

Miért ???

Végrehajtási terv olvasása

TKPROF jelentés olvasása

execution plan

Kinyomtatva

21 oldalnyi leírás, amit lehetetlenség 1 óra alattrészletesen tárgyalni

Az itteni rengeteg példakód, végrehajtási tervek,és TKPROF jelentések valószínűlegolvashatatlanok a diáról – de fehér papíron jólolvashatóak

Letölthető: www.dbspecialists.com/presentations

Végrehajtási terv és EXPLAINPLAN

Egy végrehajtási terv olyan lépések listája, amelyekszerint az Oracle végre fogja hajtani az SQLutasításokat. A tevékenységek véges számú alaputasításból állnak az adatbázis szerver számára.Még a legösszetettebb SQL utasítás is felbontható alegalapvetőbb utasítások sorozataira.

EXPLAIN PLAN egy olyan kifejezés, amely által azOracle képes elkészíteni a végrehajtási tervet,bármely SQL utasításhoz, anélkül hogy futtatnikéne. A plan table lekérdezésével lehet megnézni avégrehajtási tervet.

A tervtábla

A plan table tartalmazza az EXPLAN PLANutasítással létrehozott végrehajtási terveket.

Az általános elnevezése plan_table, deakármilyen más elnevezés is használható.

Létrehozáshoz futtassuk az utlxplan.sql-t a$ORACLE_HOME/rdbms/admin könyvtárból!

Fontos oszlopoka plan table-ből

statement_id Egyedi azonosító a végrehajtási tervhez

timestampMikor jött létre

operationA végrehajtási terv egy lépésébenvégrehajtott műlevet. PL.: „table acces”

optionsTovábbi információk a műveletről,

PL.: „by index ROWID”

object_nameA hozzáfért tábla, index, nézet, stb. neve

optimizerOptimalizációs cél, amit a létrehozáskoradtunk meg

idA végrehajtási terv lépéseinek azonosítója

parent_idA szülő lépés azonosítója

EXPLAIN PLANfeltételek

INSERT jogosultság a tervtáblára

Az elemzendő utasítás végrehajtásáhozszükséges összes jogosultság

SELECT jogosultság azokra anézettáblákra, táblákra, amelyeket implicitvagy explicit módon használ a lekérdezés

EXPLAIN PLANSzintaxis

EXPLAIN PLAN

[SET STATEMENT_ID = <string in single quotes>]

[INTO <plan table name>]

FOR

<SQL statement>;

Végrehajtási terv lekérdezése aPlan Table-ből

Használj CONNECT BY szerkezetet a tervoperátorhierarchiájának megjelenítésére

Használj LPAD-ot a sorok megkülönböztetésére, ahierarchia olvashatóbbá tételéhez

Tegyél statement_id-t a WHERE részbe, hogyegyszerre csak egy végrehajtási tervvel dolgozz

A példa szkript a következő dián mutatja alegfontosabbakat

Ezt is próbálhatod: utlxpls.sql or utlxplp.sql in$ORACLE_HOME/rdbms/admin

A végrehajtási terv lekérdezéseegyszerűen

SET VERIFY OFF

ACCEPT stmt_id CHAR PROMPT "Enter statement_id: "

COL id FORMAT 999

COL parent_id FORMAT 999 HEADING "PARENT"

COL operation FORMAT a35 TRUNCATE

COL object_name FORMAT a30

SELECT id, parent_id, LPAD (' ', LEVEL - 1) ||

operation || ' ' || options operation,

object_name

FROM plan_table

WHERE statement_id = '&stmt_id'

START WITH id = 0

AND statement_id = '&stmt_id'

CONNECT BY PRIOR id = parent_id

AND statement_id = '&stmt_id';

Végrehajtási tervpélda

SQL> EXPLAIN PLAN SET statement_id = 'demo' FOR

2 SELECT a.customer_name, a.customer_number, b.invoice_number,

3 b.invoice_type, b.invoice_date, b.total_amount,

4 c.line_number, c.part_number, c.quantity, c.unit_cost

5 FROM customers a, invoices b, invoice_items c

6 WHERE c.invoice_id = :b1

7 AND c.line_number = :b2

8 AND b.invoice_id = c.invoice_id

9 AND a.customer_id = b.customer_id;

Explained.

SQL> @explain.sql

Enter statement_id: demo

ID PARENT OPERATION OBJECT_NAME

---- ------ ----------------------------------- -----------------

0 SELECT STATEMENT

1 0 NESTED LOOPS

2 1 NESTED LOOPS

3 2 TABLE ACCESS BY INDEX ROWID INVOICE_ITEMS

4 3 INDEX UNIQUE SCAN INVOICE_ITEMS_PK

5 2 TABLE ACCESS BY INDEX ROWID INVOICES

6 5 INDEX UNIQUE SCAN INVOICES_PK

7 1 TABLE ACCESS BY INDEX ROWID CUSTOMERS

8 7 INDEX UNIQUE SCAN CUSTOMERS_PK

Egyéb lehetőségek végrehajtásiterv kiírására

Autotrace funkció SQL*Plus-ban

Teljesítmény növelő eszközök

TOAD, Quest Software:

http://www.toadsoft.com/downld.html

SET AUTOTRACE OFF|ON|TRACEONLY [EXPLAIN] [STATISTICS]

Autotrace kimeneti példaSQL*PLUS-ból

végrehajtási terv

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=39)

1 0 NESTED LOOPS (Cost=4 Card=1 Bytes=39)

2 1 NESTED LOOPS (Cost=3 Card=1 Bytes=27)

3 2 TABLE ACCESS (BY INDEX ROWID) OF 'INVOICE_ITEMS' (Cost

=2 Card=1 Bytes=15)

4 3 INDEX (UNIQUE SCAN) OF 'INVOICE_ITEMS_PK' (UNIQUE) (

Cost=1 Card=2)

5 2 TABLE ACCESS (BY INDEX ROWID) OF 'INVOICES' (Cost=1 Ca

rd=2 Bytes=24)

6 5 INDEX (UNIQUE SCAN) OF 'INVOICES_PK' (UNIQUE)

7 1 TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMERS' (Cost=1 Car

d=100 Bytes=1200)

8 7 INDEX (UNIQUE SCAN) OF 'CUSTOMERS_PK' (UNIQUE)

Egyszerű plan nézetTOAD-ban

EXPLAIN PLAN korlátai

Az explain plan kifejezés jó becslést nyújt arra, amit az Oraclehasználna. A valóban használt PLAN esetleg különbözhet azEXPLAIN PLAN-ben leírtaktól az alábbiak miatt:

Optimalizátor statisztikák, kurzor-megosztás, változók használata,dinamikus instancia paraméterek

–EXPLAIN PLAN nem tudja figyelembe venni, ha a változókfutáskor kapnak értéket

–EXPLAIN PLAN nem ellenőrzi a könyvtár cache-t, hogy akifejezés le van-e már fordítva.

EXPLAIN PLAN nem működik néhány lekérdezésnél:

beágyazott (nested) táblák:

ORA-22905: cannot access rows from a non-nested table item

Aktuális végrehajtási terv (EP)megtekintése

A v$sql view mutaja a kifejezéseket a könyvtár cache-ből. Itttalálható a cím, hash érték és gyerekszám a kérdéseskifejezéshez.

A v$sql_plan nézettábla megadja minden kifejezéshez azaktuális EP-t, annak címét, hash értékét és gyerekszámát.Oszlopai a plan table-éhez hasonlóak.

A v$sql_plan_statistics nézet mutatja az aktuálisstatisztikákat (sorok, pufferinput, eltelt idő, stb.) mindenEP-beli művelethez

A v$sql_plan és v$sql_plan_statistics nézetek az Oracle 9i-től érhetőek el.

Az aktuális EP lekérdezése

SET VERIFY OFF

COL id FORMAT 999

COL parent_id FORMAT 999 HEADING "PARENT"

COL operation FORMAT a35 TRUNCATE

COL object_name FORMAT a30

SELECT id, parent_id, LPAD (' ', LEVEL - 1) ||

operation || ' ' || options operation, object_name

FROM (

SELECT id, parent_id, operation, options, object_name

FROM v$sql_plan

WHERE address = '&address'

AND hash_value = &hash_value

AND child_number = &child_number

)

START WITH id = 0

CONNECT BY PRIOR id = parent_id;

Nyomkövető(trace file) fájlokés TKPROF

Az adatbázis sessiont kezelő szerverprocesszrészletes trace file-t készít, ha az SQL nyomkövetésengedélyezve van a sessionhöz.

A TKPROF egy Oracle alkalmazás, ami olvashatóváalakítja az SQL trace-t. Ezt az operációs rendszerparancssorából hívhatod meg. Nincs grafikusfelülete! Az Oracle 9i –től kezdve a TKPROF tudjaolvasni a kiterjesztett SQL trace fileokat.

SQL Trace engedélyezése

 Instancia szintjént:

sql_trace = true

timed_statistics = true (optional)

 A saját session-ödben:

ALTER SESSION SET sql_trace = TRUE;

ALTER SESSION SET timed_statistics = TRUE; (optional)

 Másik session-ben:

SYS.dbms_system.set_sql_trace_in_session

(<SID>, <serial#>, TRUE)

A trace fájl megtalálása

Nyisd meg a user dump útvonalat. Az OFA-ttámogató gépeken ez a:$ORACLE_BASE/admin/$ORACLE_SID/udump

A timestampek és file tartalmából nézd meg,hogy melyik trace fájl a tied.

Ha az adminisztrátoron kívül más is hozzájukakar férni, a unix paraméter fájlbaírd:_trace_files_public = true.

Ha lehetséges, dedikált szerver kapcsolatothasználj, ha a nyomkövetés aktív.

Trace file formázásaa TKPROF-fal

Így hívd meg a TKPROF alkalmazást azoperációs rendszer promptjából:

tkprof <trace file> <output file> \

[explain=<username/password>] \

[sys=n] [sort=<keyword>]

TKPROF parancssorargumentumok

trace fileAz SQL trace file, amit formázni szeretnénk

output fileTKPROF kimenete

explain=Használandó adatbázis login, ha a kimenet EP-tis tartalmazni fog.

sort=Nyomkövetett SQL kifejezések rendezett kilistázása

tkprof <trace file> <output file> \

[explain=<username/password>] \

[sys=n] [sort=<keyword>]

TKPROF outputpélda

SELECT a.customer_name, a.customer_number, b.invoice_number,

b.invoice_type, b.invoice_date, b.total_amount, c.line_number,

c.part_number, c.quantity, c.unit_cost

FROM customers a, invoices b, invoice_items c

WHERE c.invoice_id = :b1

AND c.line_number = :b2

AND b.invoice_id = c.invoice_id

AND a.customer_id = b.customer_id

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.05 0.02 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 0.00 0.00 8 8 0 1

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 4 0.05 0.02 8 8 0 1

Misses in library cache during parse: 1

Optimizer goal: CHOOSE

Parsing user id: 34 (RSCHRAG)

Mire jó a TKPROF riport és azEXPLAIN PLAN?

Fejlesztés alatt álló alkalmazások beállítása

A lassúnak bizonyuló alkalmazások utólagos hangolása

Költségbecslés az ad-hoc lekérdezések megvalósításához

Az alkamazásokhoz szükséges erőforrásmennyiségkiszámolása

Ezek a segédeszközök létfontosságúak az alkalmazásgyorsításához. Alkalmazásszintű gyorsítás szükséges anagy teljesítményű rendszerekhez! Az EXPLAIN PLAN,v$sql_plan, and TKPROF lehetőséget ad akövetkezőkre:

Végrehajtási terv olvasása

“A tervet belülről kifele olvassuk?”

Ez nem teljesen igaz!

Ehelyett, alkalmazzuk ezt:

a) Kezdjük a legkülső lépéssel

b) Keressük meg azt a lépést/lépéseket amelyek közvetlen inputotszolgáltatnak az (a)-ban szereplő lépésnek.

c) A (b)-beli lépéseket értékeljük ki. Itt is szükség lehet a (b) pontrekurzív alkalmazására, (input megtalálása, majd kiértékelés).

Egy végrehajtási terv lépések hierarchikus listája. Mindegyiklépés egy az adatbázis szerver által ismert egyszerűadathozzáférési művelet. A legbonyolultabb SQL kifejezés islebontható több egyszerű utasításra

Végrehajtási tervpélda #1

SELECT customer_id, customer_name

FROM customers

WHERE UPPER (customer_name) LIKE 'ACME%'

ORDER BY customer_name;

OPERATION OBJECT_NAME

------------------------------ --------------

SELECT STATEMENT

SORT ORDER BY

TABLE ACCESS FULL CUSTOMERS

Végrehajtási tervműveletek

TABLE ACCESS FULL

A teljes tábla átnézése, a WHERE feltételt kielégítő sorokvisszaadása. Input: nincs alárendelt operátor. Output: azokaz oszlopok, amik minden feltételt kielégítenek.

SORT ORDER BY

Az input sorok rendezése, az ORDER BY kielégítéséhez.Input: rendezni kívánt sorok. Output: a sorok, rendezve.

Végrehajtási tervPélda#2

SELECT a.customer_name, b.invoice_number,

b.invoice_date

FROM customers a, invoices b

WHERE b.invoice_date > TRUNC (SYSDATE - 1)

AND a.customer_id = b.customer_id;

OPERATION OBJECT_NAME

------------------------------ --------------

SELECT STATEMENT

NESTED LOOPS

TABLE ACCESS BY INDEX ROWID INVOICES

INDEX RANGE SCAN INVOICES_DATE

TABLE ACCESS BY INDEX ROWID CUSTOMERS

INDEX UNIQUE SCAN CUSTOMERS_PK

Végrehajtási tervMűveletek

INDEX UNIQUE SCAN

Egy teljes kulcs megkeresése egy egyedi (unique)indexben. Input: általában nincs alárendelt operátor.Kulcs értékek az eredeti lekérdezésből vagy egy szülőművelettől. Output: üres vagy egy ROWID az indexből.

INDEX RANGE SCAN

Egy kulcs megkeresése egy nem egyedi (non unique)indexben vagy egy nem teljes kulcs egy unique indexben.Input: általában nincs alárendelt operátor. Output: üres vagytöbb ROWID az indexből.

Végrehajtási tervMűveletek

TABLE ACCESS BY INDEX ROWID

Sorok megkeresése ROWID alapján. Input: ROWID-eklistája. Output: A ROWID-ekhez tartozó sorok oszlopai.

NESTED LOOPS

Sorok összekapcsolása beágyazott ciklussal (nestedloop)-al. Inputs: két sorhalmaza. Output: azösszekapcsolás eredménye.

Az első inputhalmaz minden sorához az Oraclevégrehajtja a második inputhalmazhoz tartozóműveleteket egyszer, és az illeszkedő sorok adják azoutputot.

Végrehajtási tervPélda #3

SELECT a.customer_name,

COUNT (DISTINCT b.invoice_id) open_invs,

COUNT (c.invoice_id) open_inv_items

FROM customers a, invoices b, invoice_items c

WHERE b.invoice_status = 'OPEN'

AND a.customer_id = b.customer_id

AND c.invoice_id (+) = b.invoice_id

GROUP BY a.customer_name;

OPERATION OBJECT_NAME

-------------------------------- ----------------

SELECT STATEMENT

SORT GROUP BY

NESTED LOOPS OUTER

HASH JOIN

TABLE ACCESS BY INDEX ROWID INVOICES

INDEX RANGE SCAN INVOICES_STATUS

TABLE ACCESS FULL CUSTOMERS

INDEX RANGE SCAN INVOICE_ITEMS_PK

Végrehajtási tervMűveletek

HASH JOIN

Sorok összekapcsolása hash joinnal. Inputs: kétsorhalmaz. Output: az összekapcsolás eredménye.

Minden sort beolvas a második inputból, felépíti ahash struktúrát, mielőtt egyenként beolvasná az elsőinputhoz tartozó sorokat.

Az első inputhalmaz minden rekordjához a hashelésalapján megkeresi az illeszkedő rekordokat a másikhalmazból.

Végrehajtási tervMűveletek

NESTED LOOPS OUTER

Ugyanaz mint a NESTED_LOOP, csak itt külsőösszekapcsolás történik.

SORT GROUP BY

Ugyanaz mint a SORT ORDER BY, csak itt a soroka group by szerint vannak rendezve.

Végrehajtási tervPélda #4

SELECT customer_name

FROM customers a

WHERE EXISTS

(SELECT 1

FROM invoices_view b

WHERE b.customer_id = a.customer_id

AND number_of_lines > 100)

ORDER BY customer_name;

CREATE OR REPLACE VIEW invoices_view AS

SELECT a.invoice_id, a.customer_id,

COUNT(*) number_of_lines

FROM invoices a, invoice_items b

WHERE b.invoice_id = a.invoice_id

GROUP BY a.invoice_id, a.customer_id;

Végrehajtási tervPélda #4 (folytatás)

OPERATION OBJECT_NAME

----------------------------------- -------------

SELECT STATEMENT

SORT ORDER BY

FILTER

TABLE ACCESS FULL CUSTOMERS

VIEW INVOICES_VIEW

FILTER

SORT GROUP BY

NESTED LOOPS

TABLE ACCESS BY INDEX ROWID INVOICES

INDEX RANGE SCAN INVS_CUST_ID

INDEX RANGE SCAN INV_ITEMS_PK

Végrehajtási tervMűveletek

FILTER

Valamilyen feltétel alapján, adott sorokból sorokat dobel. A feltétel meghatározásához szükség lehet egymásik inputhalmaz műveleteinek elvégzésére. Input: avizsgálandó sorok, esetenként még, egyébalműveletek, amiket minden sorra végre kell hajtani azelső inputból a feltétel kiértékelése előtt. Output: Azoka sorok, amik eleget tesznek a feltételnek.

Végrehajtási tervMűveletek

VIEW

Nézettábla fizikai reprezentációjánaklétrehozása. Input: sorok. Output: a nézetetimplementáló sorok.

Megjegyzések a végrehajtásiterv műveleteihez

Az optimalizátor az allekérdezéseketösszekapcsolássá alakítja, és beolvasztja a főlekérdezésbe, amikor csak lehetséges.

Ha egy allekérdezés teljesen különbözik, és nem lehetbeolvasztani a fő lekérdezésbe, az optimalizátorteljesen külön lekérdezésként is kezelheti éskihagyhatja a fő lekérdezés végrehajtási tervéből.

Az optimalizátor kiegészíti a nézeteket és beolvasztjaa lekérdezésbe, ha lehetséges. Egy nézet műveletakkor jelenik meg a végrehajtási tervben, ha a nézetdefiníciót nem lehetett beolvasztani.

Végrehajtási tervPélda #5

SELECT /*+ RULE */ a.cust_name, b.contact_name

FROM customers a, contacts@sales.acme.com b

WHERE UPPER(b.contact_name) = UPPER(a.cust_name);

végrehajtási terv

------------------------------------------------

0 SELECT STATEMENT Optimizer=HINT: RULE

1 0 MERGE JOIN

2 1 SORT (JOIN)

3 2 REMOTE* SALES.ACME.COM

4 1 SORT (JOIN)

5 4 TABLE ACCESS (FULL) OF 'CUSTOMERS'

3 SERIAL_FROM_REMOTE SELECT "CONTACT_NAME"

FROM "CONTACTS" "B”

Végrehajtási tervMűveletek

REMOTE

Egy SQL kifejezés elküldése egy távoli adatbázisnak azOracle Net-en keresztül. Input: nincs alművelet. Output:A lekérdezés eredménye a távoli adatbázisból.

Végrehajtási tervMűveletek

SORT JOIN

Ugyanaz mint a SORT GROUP BY, csak itt az input ajoin oszlop, vagy oszlopok alapján lesz rendezve,ahhoz, hogy merge joint lehessen használni.

Végrehajtási tervMűveletek

MERGE JOIN

Sorok összekapcsolása merge joinnal. Inputs: kétsorhalmaza Output: az összekapcsoláseredménye.

Az Oracle felváltva olvas mindkét inputhalmazból,és összeilleszti a megfelelő rekordokat. A kéthalmazról feltesszük, hogy az összekapcsolásioszlop vagy oszlopokban rendezettek.

Műveletek összefoglalása

-TABLE ACCESS FULL

-TABLE ACCESS BY INDEX ROWID

-INDEX UNIQUE SCAN

-INDEX RANGE SCAN

-NESTED LOOPS

-NESTED LOOPS OUTER

-HASH JOIN

-MERGE JOIN

-FILTER

-VIEW

-REMOTE

-SORT ORDER BY

-SORT GROUP BY

-SORT JOIN

Nem néztük végig az összes végrehajtási terv műveletet,csak a leggyakoribbakat:

TKPROF riport elemei

Riport fejléc

–TKPROF verzió, futtatás dátuma, rendezési opció, tracefájl

Minden SQL kifejezéshez külön bejegyzés a trace fájlban.

–SQL kifejezés lista

–OCI hívó statisztika: elemzések (parse) száma, execute ésfetch hívások, feldolgozott sorok, felhasznált idő és I/O

–Elemzési információ: elemző felhasználó, rekurzívmélység, a könyvtár cache hiányzik, optimalizáló mód

–Lapműveletek száma

–Execution plan listázás (opcionális)

–Várakozási események listája (opcionális)

TKPROF riport elemei(folytatás)

Riport összefoglalás

–OCI hívási statisztikák.

–A trace fájlban talált lekérdezések száma, hány sortad vissza egy művelet.

TKPROF ReportFejléc

TKPROF: Release 8.1.6.1.0 - Production on Wed Aug 9 19:06:36 2000

Trace file: example.trc

Sort options: default

************************************************************************

count = number of times OCI procedure was executed

cpu = cpu time in seconds executing

elapsed = elapsed time in seconds executing

disk = number of physical reads of buffers from disk

query = number of buffers gotten for consistent read

current = number of buffers gotten in current mode (usually for update)

rows = number of rows processed by the fetch or execute call

OCI hívási statisztikák

SELECT table_name

FROM user_tables

ORDER BY table_name

call count cpu elapsed disk query current rows

------- ------ -------- ---------- --------- --------- --------- ---------

Parse 1 0.01 0.02 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 14 0.59 0.99 0 33633 0 194

------- ------ -------- ---------- --------- --------- --------- ---------

total 16 0.60 1.01 0 33633 0 194

Misses in library cache during parse: 1

Optimizer goal: CHOOSE

Parsing user id: RSCHRAG [recursive depth: 0]

Mit mond a TKPROF riportaz előző dián?

Az utasítást egyszer fordította le az Oracle atracelés bekapcsolása óta.

A feldolgozás 0.01 CPU időbe és 0.02másodpercbe telt.

Nem volt I/O vagy pufferolvasás, feltételezhető,hogy minden a dictionary cache-ben volt.

Az Oracle egyszer futtatta le ezt a lekérdezést.

14 fetch történt, és összesen 194 sor lettvisszaadva.

Mit mond a TKPROF riportaz előző dián? (folyt.)

A fetch 0.59 CPU időbe, 0.99 másodpercbe telt.

A fetch alatt 33,633 pufferolvasás történt konzisztensmódban, de nem volt fizikai olvasásra szükség.

A kifejezés nem volt a library cache –ben (shared pool)amikor a parse hívás történt.

Költségalapú optimalizálás történt.

Az RSCHRAG nevű felhasználó volt az adatbázishozkapcsolódva, amikor a parse történt.

Az utasítás végrehajtása közvetlenül történt, nemrekurzív hívás vagy trigger hatására.

A műveletek által visszaadotteredménysorok

Rows Row Source Operation

------- ---------------------------------------------------

194 SORT ORDER BY

194 NESTED LOOPS

195 NESTED LOOPS OUTER

195 NESTED LOOPS

11146 TABLE ACCESS BY INDEX ROWID OBJ$

11146 INDEX RANGE SCAN (object id 34)

11339 TABLE ACCESS CLUSTER TAB$

12665 INDEX UNIQUE SCAN (object id 3)

33 INDEX UNIQUE SCAN (object id 33)

193 TABLE ACCESS CLUSTER SEG$

387 INDEX UNIQUE SCAN (object id 9)

194 TABLE ACCESS CLUSTER TS$

388 INDEX UNIQUE SCAN (object id 7)

Végrehajtási terv

Rows végrehajtási terv

------- ---------------------------------------------------

0 SELECT STATEMENT GOAL: CHOOSE

194 SORT (ORDER BY)

194 NESTED LOOPS

195 NESTED LOOPS (OUTER)

195 NESTED LOOPS

11146 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$'

11146 INDEX (RANGE SCAN) OF 'I_OBJ2' (UNIQUE)

11339 TABLE ACCESS (CLUSTER) OF 'TAB$'

12665 INDEX (UNIQUE SCAN) OF 'I_OBJ#' (NON-UNIQUE)

33 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE)

193 TABLE ACCESS (CLUSTER) OF 'SEG$'

387 INDEX (UNIQUE SCAN) OF 'I_FILE#_BLOCK#' (NON-UNIQUE)

194 TABLE ACCESS (CLUSTER) OF 'TS$'

388 INDEX (UNIQUE SCAN) OF 'I_TS#' (NON-UNIQUE)

Megjegyzések a TKPROF ésvégrehajtási tervhez

Execution plans tervek csak akkor lesznek a TKPROFriportokban, ha az explain= paraméter be van állítva aTKPROF meghívásakor.

A TKPROF létrehozza és eldobja a saját plan table-jeit,ha nem létezett korábban.

A visszaadott sorok száma nem becslés, hanem azaktuális pontos adat. Ez nagy segítség, amikor gyengénteljesítő lekérdezéseken akarunk javítani.

A TKPROF által futtatott EXPLAIN PLAN eltérhet attól,amit traced session-ban használt.

TKPROF Riportok:Több mint egyszerű végrehajtási tervek

SQL kifejezések és a könyvtár cache használata segítannak az eldöntésében, hogy az alkalmazások jólkihasználják az Oracle’s osztott SQL lehetőségeit.

A Parse, execute, and fetch call számlálók segítenekeldönteni, hogy az alkalmazások jól használják-e azOracle API-t.

CPU és I/O adatok semennyit sem segítenek azerőforrás igényes SQL lekérdezések esetében.

A részműveletek által visszaadott sorok számaisegítenek átalakítani a nem megfelelő végrehajtásiterveket.

Összefoglaló

Használj EP-t a v$sql_plan lekérdezése helyett,SQL*Plus-ban autotrace lehetőséget, vagy GUIeszközöket hogy megnézd az végrehajtási terveket.

Használd a TKPROF-ot az SQL trace fájlokolvashatóvá tételéhez.

EP-k és TKPROF riportok rengeteg információtszolgáltatnak az adminisztrátornak, amik jobbanműködő és gazdaságosabb alkalmazások készítésétteszik lehetővé.

The catch: Tudnod kell értelmezni az EP-ket ésTKPROF riportokat, hogy valami hasznod legyenbelőlük. Azt is jó, ha tudod, mikor kell EP-t használnia v$sql_plan lekérdezés helyett.