1 Végrehajtási terv és TKPROF a hatákonyság növelésére Roger Schrag Database Specialists, Inc.

2 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

3 Kinyomtatva  21 oldalnyi leírás, amit lehetetlenség 1 óra alatt részletesen tárgyalni  Az itteni rengeteg példakód, végrehajtási tervek, és TKPROF jelentések valószínűleg olvashatatlanok a diáról – de fehér papíron jól olvashatóak  Letölthető:

4 Végrehajtási terv és EXPLAIN PLAN  Egy végrehajtási terv olyan lépések listája, amelyek szerint az Oracle végre fogja hajtani az SQL utasításokat. A tevékenységek véges számú alap utasításból állnak az adatbázis szerver számára. Még a legösszetettebb SQL utasítás is felbontható a legalapvetőbb utasítások sorozataira.  EXPLAIN PLAN egy olyan kifejezés, amely által az Oracle képes elkészíteni a végrehajtási tervet, bármely SQL utasításhoz, anélkül hogy futtatni kéne. A plan table lekérdezésével lehet megnézni a végrehajtási tervet.

5 A tervtábla  A plan table tartalmazza az EXPLAN PLAN utasítással létrehozott végrehajtási terveket.  Az általános elnevezése plan_table, de aká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!

6 Fontos oszlopok a 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ében vé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áskor adtunk meg idA végrehajtási terv lépéseinek azonosítója parent_idA szülő lépés azonosítója

7 EXPLAIN PLAN feltételek  INSERT jogosultság a tervtáblára  Az elemzendő utasítás végrehajtásához szükséges összes jogosultság  SELECT jogosultság azokra a nézettáblákra, táblákra, amelyeket implicit vagy explicit módon használ a lekérdezés

8 EXPLAIN PLAN Szintaxis EXPLAIN PLAN [SET STATEMENT_ID = ] [INTO ] FOR ;

9 Végrehajtási terv lekérdezése a Plan Table-ből  Használj CONNECT BY szerkezetet a terv operátorhierarchiájának megjelenítésére  Használj LPAD-ot a sorok megkülönböztetésére, a hierarchia olvashatóbbá tételéhez  Tegyél statement_id-t a WHERE részbe, hogy egyszerre csak egy végrehajtási tervvel dolgozz  A példa szkript a következő dián mutatja a legfontosabbakat  Ezt is próbálhatod: utlxpls.sql or utlxplp.sql in $ORACLE_HOME/rdbms/admin

10 A végrehajtási terv lekérdezése egyszerű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';

11 Végrehajtási terv pé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. Enter statement_id: demo ID PARENT OPERATION OBJECT_NAME 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

12 Egyéb lehetőségek végrehajtási terv kiírására  Autotrace funkció SQL*Plus-ban  Teljesítmény növelő eszközök TOAD, Quest Software: SET AUTOTRACE OFF|ON|TRACEONLY [EXPLAIN] [STATISTICS]

13 Autotrace kimeneti példa SQL*PLUS-ból végrehajtási terv 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)

14 Egyszerű plan nézet TOAD-ban

15 EXPLAIN PLAN korlátai  Az explain plan kifejezés jó becslést nyújt arra, amit az Oracle használna. A valóban használt PLAN esetleg különbözhet az EXPLAIN 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ók futáskor kapnak értéket –EXPLAIN PLAN nem ellenőrzi a könyvtár cache-t, hogy a kifejezé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

16 Aktuális végrehajtási terv (EP) megtekintése  A v$sql view mutaja a kifejezéseket a könyvtár cache-ből. Itt található a cím, hash érték és gyerekszám a kérdéses kifejezéshez.  A v$sql_plan nézettábla megadja minden kifejezéshez az aktuá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ális statisztikákat (sorok, pufferinput, eltelt idő, stb.) minden EP-beli művelethez  A v$sql_plan és v$sql_plan_statistics nézetek az Oracle 9i- től érhetőek el.

17 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;

18 Nyomkövető(trace file) fájlok és TKPROF  Az adatbázis sessiont kezelő szerverprocessz részletes trace file-t készít, ha az SQL nyomkövetés engedé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 rendszer parancssorából hívhatod meg. Nincs grafikus felülete! Az Oracle 9i –től kezdve a TKPROF tudja olvasni a kiterjesztett SQL trace fileokat.

19 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 (,, TRUE)

20 A trace fájl megtalálása  Nyisd meg a user dump útvonalat. Az OFA-t tá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ájuk akar férni, a unix paraméter fájlba írd: _trace_files_public = true.  Ha lehetséges, dedikált szerver kapcsolatot használj, ha a nyomkövetés aktív.

21 Trace file formázása a TKPROF-fal Így hívd meg a TKPROF alkalmazást az operációs rendszer promptjából: tkprof \ [explain= ] \ [sys=n] [sort= ]

22 TKPROF parancssor argumentumok trace fileAz SQL trace file, amit formázni szeretnénk output fileTKPROF kimenete explain=Használandó adatbázis login, ha a kimenet EP-t is tartalmazni fog. sort=Nyomkövetett SQL kifejezések rendezett kilistázása tkprof \ [explain= ] \ [sys=n] [sort= ]

23 TKPROF output pé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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 34 (RSCHRAG)

24 Mire jó a TKPROF riport és az EXPLAIN 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ég kiszámolása Ezek a segédeszközök létfontosságúak az alkalmazás gyorsításához. Alkalmazásszintű gyorsítás szükséges a nagy teljesítményű rendszerekhez! Az EXPLAIN PLAN, v$sql_plan, and TKPROF lehetőséget ad a következőkre:

25 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 inputot szolgá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) pont rekurzív alkalmazására, (input megtalálása, majd kiértékelés). Egy végrehajtási terv lépések hierarchikus listája. Mindegyik lépés egy az adatbázis szerver által ismert egyszerű adathozzáférési művelet. A legbonyolultabb SQL kifejezés is lebontható több egyszerű utasításra

26 Végrehajtási terv pé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

27 Végrehajtási terv műveletek TABLE ACCESS FULL A teljes tábla átnézése, a WHERE feltételt kielégítő sorok visszaadása. Input: nincs alárendelt operátor. Output: azok az 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.

28 Végrehajtási terv Pé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

29 Végrehajtási terv Mű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 vagy több ROWID az indexből.

30 Végrehajtási terv Műveletek TABLE ACCESS BY INDEX ROWID Sorok megkeresése ROWID alapján. Input: ROWID-ek listája. Output: A ROWID-ekhez tartozó sorok oszlopai. NESTED LOOPS Sorok összekapcsolása beágyazott ciklussal (nested loop)-al. Inputs: két sorhalmaza. Output: az összekapcsolás eredménye. Az első inputhalmaz minden sorához az Oracle végrehajtja a második inputhalmazhoz tartozó műveleteket egyszer, és az illeszkedő sorok adják az outputot.

31 Végrehajtási terv Pé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

32 Végrehajtási terv Műveletek HASH JOIN Sorok összekapcsolása hash joinnal. Inputs: két sorhalmaz. Output: az összekapcsolás eredménye. Minden sort beolvas a második inputból, felépíti a hash struktúrát, mielőtt egyenként beolvasná az első inputhoz tartozó sorokat. Az első inputhalmaz minden rekordjához a hashelés alapján megkeresi az illeszkedő rekordokat a másik halmazból.

33 Végrehajtási terv Mű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 sorok a group by szerint vannak rendezve.

34 Végrehajtási terv Pé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;

35 Végrehajtási terv Pé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

36 Végrehajtási terv Műveletek FILTER Valamilyen feltétel alapján, adott sorokból sorokat dob el. A feltétel meghatározásához szükség lehet egy másik inputhalmaz műveleteinek elvégzésére. Input: a vizsgálandó sorok, esetenként még, egyéb alműveletek, amiket minden sorra végre kell hajtani az első inputból a feltétel kiértékelése előtt. Output: Azok a sorok, amik eleget tesznek a feltételnek.

37 Végrehajtási terv Műveletek VIEW Nézettábla fizikai reprezentációjának létrehozása. Input: sorok. Output: a nézetet implementáló sorok.

38 Megjegyzések a végrehajtási terv 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 lehet beolvasztani a fő lekérdezésbe, az optimalizátor teljesen külön lekérdezésként is kezelheti és kihagyhatja a fő lekérdezés végrehajtási tervéből.  Az optimalizátor kiegészíti a nézeteket és beolvasztja a lekérdezésbe, ha lehetséges. Egy nézet művelet akkor jelenik meg a végrehajtási tervben, ha a nézet definíciót nem lehetett beolvasztani.

39 Végrehajtási terv Példa #5 SELECT /*+ RULE */ a.cust_name, b.contact_name FROM customers a, b WHERE UPPER(b.contact_name) = UPPER(a.cust_name); végrehajtási terv 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”

40 Végrehajtási terv Műveletek REMOTE Egy SQL kifejezés elküldése egy távoli adatbázisnak az Oracle Net-en keresztül. Input: nincs alművelet. Output: A lekérdezés eredménye a távoli adatbázisból.

41 Végrehajtási terv Műveletek SORT JOIN Ugyanaz mint a SORT GROUP BY, csak itt az input a join oszlop, vagy oszlopok alapján lesz rendezve, ahhoz, hogy merge joint lehessen használni.

42 Végrehajtási terv Műveletek MERGE JOIN Sorok összekapcsolása merge joinnal. Inputs: két sorhalmaza Output: az összekapcsolás eredménye. Az Oracle felváltva olvas mindkét inputhalmazból, és összeilleszti a megfelelő rekordokat. A két halmazról feltesszük, hogy az összekapcsolási oszlop vagy oszlopokban rendezettek.

43 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:

44 TKPROF riport elemei  Riport fejléc –TKPROF verzió, futtatás dátuma, rendezési opció, trace fá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 és fetch hívások, feldolgozott sorok, felhasznált idő és I/O –Elemzési információ: elemző felhasználó, rekurzív mé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)

45 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 sort ad vissza egy művelet.

46 TKPROF Report Fejléc TKPROF: Release Production on Wed Aug 9 19:06: (c) Copyright 1999 Oracle Corporation. All rights reserved. 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

47 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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: RSCHRAG [recursive depth: 0]

48 Mit mond a TKPROF riport az előző dián?  Az utasítást egyszer fordította le az Oracle a tracelés bekapcsolása óta.  A feldolgozás 0.01 CPU időbe és 0.02 má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 lett visszaadva.

49 Mit mond a TKPROF riport az 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 konzisztens mó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ázishoz kapcsolódva, amikor a parse történt.  Az utasítás végrehajtása közvetlenül történt, nem rekurzív hívás vagy trigger hatására.

50 A műveletek által visszaadott eredménysorok Rows Row Source Operation SORT ORDER BY 194 NESTED LOOPS 195 NESTED LOOPS OUTER 195 NESTED LOOPS TABLE ACCESS BY INDEX ROWID OBJ$ INDEX RANGE SCAN (object id 34) TABLE ACCESS CLUSTER TAB$ 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)

51 Végrehajtási terv Rows végrehajtási terv SELECT STATEMENT GOAL: CHOOSE 194 SORT (ORDER BY) 194 NESTED LOOPS 195 NESTED LOOPS (OUTER) 195 NESTED LOOPS TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' INDEX (RANGE SCAN) OF 'I_OBJ2' (UNIQUE) TABLE ACCESS (CLUSTER) OF 'TAB$' 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)

52 Megjegyzések a TKPROF és végrehajtási tervhez  Execution plans tervek csak akkor lesznek a TKPROF riportokban, ha az explain= paraméter be van állítva a TKPROF 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 az aktuális pontos adat. Ez nagy segítség, amikor gyengén teljesítő lekérdezéseken akarunk javítani.  A TKPROF által futtatott EXPLAIN PLAN eltérhet attól, amit traced session-ban használt.

53 TKPROF Riportok: Több mint egyszerű végrehajtási tervek  SQL kifejezések és a könyvtár cache használata segít annak az eldöntésében, hogy az alkalmazások jól kihasználják az Oracle’s osztott SQL lehetőségeit.  A Parse, execute, and fetch call számlálók segítenek eldönteni, hogy az alkalmazások jól használják-e az Oracle API-t.  CPU és I/O adatok semennyit sem segítenek az erőforrás igényes SQL lekérdezések esetében.  A részműveletek által visszaadott sorok számai segítenek átalakítani a nem megfelelő végrehajtási terveket.

54 Összefoglaló  Használj EP-t a v$sql_plan lekérdezése helyett, SQL*Plus-ban autotrace lehetőséget, vagy GUI eszközöket hogy megnézd az végrehajtási terveket.  Használd a TKPROF-ot az SQL trace fájlok olvashatóvá tételéhez.  EP-k és TKPROF riportok rengeteg információt szolgáltatnak az adminisztrátornak, amik jobban működő és gazdaságosabb alkalmazások készítését teszik lehetővé.  The catch: Tudnod kell értelmezni az EP-ket és TKPROF riportokat, hogy valami hasznod legyen belőlük. Azt is jó, ha tudod, mikor kell EP-t használni a v$sql_plan lekérdezés helyett.

55 Források  Ez és egyéb hasznos előadások letölthetőek innen:

56 Contact Information Roger Schrag Database Specialists, Inc. 388 Market Street, Suite 400 San Francisco, CA Tel: 415/ Web: