Vgrehajtsi terv s TKPROF a hatkonysg nvelsre Roger

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

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 2

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ő: www. dbspecialists. com/presentations 3

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. 4

A tervtábla § A plan table tartalmazza az EXPLAN 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! 5

Fontos oszlopok a plan table-ből statement_id timestamp operation options object_name optimizer id parent_id Egyedi azonosító a végrehajtási tervhez Mikor jött létre A végrehajtási terv egy lépésében végrehajtott műlevet. PL. : „table acces” További információk a műveletről, PL. : „by index ROWID” A hozzáfért tábla, index, nézet, stb. neve Optimalizációs cél, amit a létrehozáskor adtunk meg A végrehajtási terv lépéseinek azonosítója A szülő lépés azonosítója 6

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, amelyeket implicit vagy explicit módon használ a lekérdezés 7

EXPLAIN PLAN Szintaxis EXPLAIN PLAN [SET STATEMENT_ID = <string in single quotes>] [INTO <plan table name>] FOR <SQL statement>; 8

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 9

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 a 35 TRUNCATE COL object_name FORMAT a 30 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'; 10

Végrehajtási terv példa statement_id = 'demo' FOR SQL> EXPLAIN PLAN SET 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 = : b 1 7 AND c. line_number = : b 2 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 11

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

Autotrace kimeneti példa SQL*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) 13

Egyszerű plan nézet TOAD-ban 14

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 15

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 9 itől érhetőek el. 16

Az aktuális EP lekérdezése SET VERIFY OFF COL id FORMAT 999 COL parent_id FORMAT 999 HEADING "PARENT" COL operation FORMAT a 35 TRUNCATE COL object_name FORMAT a 30 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; 17

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 9 i –től kezdve a TKPROF tudja olvasni a kiterjesztett SQL trace fileokat. 18

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) 19

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. 20

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 <trace file> <output file> [explain=<username/password>] [sys=n] [sort=<keyword>] 21

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

TKPROF output példa SELECT a. customer_name, a. customer_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 = : b 1 AND c. line_number = : b 2 AND b. invoice_id = c. invoice_id AND a. customer_id = b. customer_id call count -------Parse 1 Execute 1 Fetch 2 -------total 4 cpu elapsed disk query current ---------- -----0. 05 0. 02 0 0 0 0. 00 8 8 0 ---------- -----0. 05 0. 02 8 8 0 rows -----0 0 1 -----1 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 34 (RSCHRAG) 23

Mire jó a TKPROF riport és az EXPLAIN PLAN? 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: § 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 24

Végrehajtási terv olvasása 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 § “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). 25

Végrehajtási terv példa #1 SELECT FROM WHERE ORDER BY customer_id, customer_name customers UPPER (customer_name) LIKE 'ACME%' customer_name; OPERATION OBJECT_NAME ---------------SELECT STATEMENT SORT ORDER BY TABLE ACCESS FULL CUSTOMERS 26

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. 27

Végrehajtási terv Példa#2 SELECT FROM WHERE AND a. customer_name, b. invoice_number, b. invoice_date customers a, invoices b b. invoice_date > TRUNC (SYSDATE - 1) a. customer_id = b. customer_id; OPERATION ---------------SELECT STATEMENT NESTED LOOPS TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS BY INDEX ROWID INDEX UNIQUE SCAN OBJECT_NAME -------INVOICES_DATE CUSTOMERS_PK 28

Végrehajtási terv Műveletek INDEX UNIQUE SCAN Egy teljes kulcs megkeresése 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. 29

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. 30

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 ----------------SELECT STATEMENT SORT GROUP BY NESTED LOOPS OUTER HASH JOIN TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN TABLE ACCESS FULL INDEX RANGE SCAN OBJECT_NAME -------- INVOICES_STATUS CUSTOMERS INVOICE_ITEMS_PK 31

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. 32

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. 33

Végrehajtási terv Példa #4 SELECT FROM WHERE customer_name customers a 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; 34

Végrehajtási terv Példa #4 (folytatás) OPERATION -----------------SELECT STATEMENT SORT ORDER BY FILTER TABLE ACCESS FULL VIEW FILTER SORT GROUP BY NESTED LOOPS TABLE ACCESS BY INDEX ROWID INDEX RANGE SCAN OBJECT_NAME ------- CUSTOMERS INVOICES_VIEW INVOICES INVS_CUST_ID INV_ITEMS_PK 35

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. 36

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. 37

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. 38

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

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. 40

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. 41

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. 42

Műveletek összefoglalása Nem néztük végig az összes végrehajtási terv műveletet, csak a leggyakoribbakat: - TABLE ACCESS FULL TABLE ACCESS BY INDEX ROWID INDEX UNIQUE SCAN INDEX RANGE SCAN NESTED LOOPS OUTER HASH JOIN MERGE JOIN FILTER VIEW REMOTE SORT ORDER BY SORT GROUP BY SORT JOIN 43

§ 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) 44

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. 45

TKPROF Report Fejléc TKPROF: Release 8. 1. 6. 1. 0 - Production on Wed Aug 9 19: 06: 36 2000 (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 46

OCI hívási statisztikák SELECT table_name FROM user_tables ORDER BY table_name call count -------Parse 1 Execute 1 Fetch 14 -------total 16 cpu elapsed disk query current ---------- ----0. 01 0. 02 0 0. 00 0 0 0 0. 59 0. 99 0 33633 0 ---------- ----0. 60 1. 01 0 33633 0 rows ----0 0 194 ----194 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: RSCHRAG [recursive depth: 0] 47

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. 48

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. 49

A műveletek által visszaadott eredménysorok Rows ------194 195 195 11146 11339 12665 33 193 387 194 388 Row Source Operation -------------------------SORT ORDER BY NESTED LOOPS OUTER NESTED LOOPS TABLE ACCESS BY INDEX ROWID OBJ$ INDEX RANGE SCAN (object id 34) TABLE ACCESS CLUSTER TAB$ INDEX UNIQUE SCAN (object id 3) INDEX UNIQUE SCAN (object id 33) TABLE ACCESS CLUSTER SEG$ INDEX UNIQUE SCAN (object id 9) TABLE ACCESS CLUSTER TS$ INDEX UNIQUE SCAN (object id 7) 50

Végrehajtási terv Rows ------0 194 195 195 11146 11339 12665 33 193 387 194 388 végrehajtási terv -------------------------SELECT STATEMENT GOAL: CHOOSE SORT (ORDER BY) NESTED LOOPS (OUTER) NESTED LOOPS TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' INDEX (RANGE SCAN) OF 'I_OBJ 2' (UNIQUE) TABLE ACCESS (CLUSTER) OF 'TAB$' INDEX (UNIQUE SCAN) OF 'I_OBJ#' (NON-UNIQUE) INDEX (UNIQUE SCAN) OF 'I_OBJ 1' (UNIQUE) TABLE ACCESS (CLUSTER) OF 'SEG$' INDEX (UNIQUE SCAN) OF 'I_FILE#_BLOCK#' (NON-UNIQUE) TABLE ACCESS (CLUSTER) OF 'TS$' INDEX (UNIQUE SCAN) OF 'I_TS#' (NON-UNIQUE) 51

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. 52

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. 53

Ö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. 54

Források § Ez és egyéb hasznos előadások letölthetőek innen: www. dbspecialists. com/presentations 55

Contact Information Roger Schrag Database Specialists, Inc. 388 Market Street, Suite 400 San Francisco, CA 94111 Tel: 415/344 -0500 Email: rschrag@dbspecialists. com Web: www. dbspecialists. com 56