rainer@lambertz-c.de Inhaltsverzeichnis 1. Eine Trace Datei 6 1.1. Session Trace 7 1.2. Trace einer beliebigen Session 7 1.3. Probleme beim Erstellen einer Trace Datei 8 1.4. Autotrace 9 2. Trace Datei und TKProf Ausgabe 11 2.1. Das Trace File im Überblick 11 2.1.1. Beschreibung der Ergebnisse in einer Trace Datei 15 2.2. Erstellen einer TKProf Datei 17 2.3. Interpretieren einer TKProf Datei 19 2.3.1. Darstellung der Ergebnisse in einer TKProf Datei 20 2.3.2. Was bildet die Differenz zwischen CPU- und elapsed time 30 3. So arbeitet Oracle 33 3.1. Auflösung eines Statement 33 3.2. Der Index 41 3.2.1. Ungünstiger CLUSTERING_INDEX 41 3.2.2. Index Selektivität 43 3.3. Verschiedene Indextypen 48 3.3.1. B*tree Index 48 3.3.2. Bitmap Index 53 3.3.3. Hash Index 53 3.4. Wann Oracle einen Index im CHOOSE Mode nicht nutzt 53 3.4.1. Zu große Anzahl von gelöscht markierten Indexeinträgen 53 3.4.2. Geringes Datenvolumen der Tabelle 54 3.4.3. Einschränkung mit!= oder <> 54 3.4.4. Unbekannte Selektivität durch Bereichsabfragen 54 3.4.5. Unbekannte Selektivität durch Einsatz von Bindevariablen 55 3.4.6. Unterbrechung der Reihenfolge von Indexattributen 55 3.4.7. Füllgrad des Index-Key 57 3.4.8. Fehlende Statistiken 59 3.4.9. Veraltete Statistiken 59 3.4.10. Abfrage mit IS NULL 59 3.4.11. Abfrage IS NOT NULL 60 3.4.12. Mehrere Indizes 60 3.4.13. Ungünstiger Clustering_Index 61 3.4.14. LIKE in der WHERE Klausel 61 4. Erklärung eines Explain Plan 63 4.1. Operationen eines Explain Plan 66 Oracle Trace Seite 2
email: rainer@lambertz-c.de 4.1.1. TABLE ACCESS (FULL) 66 4.1.2. TABLE ACCESS (CLUSTER) 66 4.1.3. TABLE ACCESS (HASH) 67 4.1.4. TABLE ACCESS (BY ROWID) 73 4.1.5. INDEX (RANGE SCAN) 74 4.1.6. INDEX (UNIQUE SCAN) 75 4.1.7. INDEX (FAST FULL SCAN) 75 4.1.8. INDEX (FULL SCAN) 77 4.1.9. INDEX (FULL SCAN (MIN/MAX)) 77 4.1.10. CONNECT BY 77 4.1.11. FILTER 77 4.1.12. MERGE JOIN 78 4.1.13. MERGE JOIN (OUTER) 78 4.1.14. MERGE JOIN (CARTESIAN) 78 4.1.15. SORT (ORDER BY) 80 4.1.16. SORT (JOIN) 80 4.1.17. SORT (AGGREGATE) 80 4.1.18. SORT (UNIQUE) 80 4.1.19. SORT (GROUP BY) 80 4.1.20. NESTED LOOPS (OUTER) 81 4.1.21. NESTED LOOPS (ANTI) 81 4.1.22. NESTED LOOPS (SEMI) 81 4.1.23. CONCATENATION 81 4.1.24. INTERSECTION 81 4.1.25. MINUS 81 4.1.26. UNION 81 4.1.27. UNION-ALL 81 4.1.28. VIEW 81 4.1.29. NESTED LOOPS 82 4.1.30. HASH JOIN 84 4.2. INDEX RANGE SCAN 85 5. Bedeutung von Tabellen und Index Statistiken 88 6. Glossar 89 6.1. Recursive calls 89 6.2. DB_BLOCK_SIZE 89 6.3. DB_FILE_MULTIBLOCK_READ_COUNT 89 6.4. Chained rows 90 6.5. Cost 91 6.6. DB Block gets 91 6.7. DB Block changes 91 6.8. Datenblöcke im Überblick 92 6.9. Extents 93 6.10. High Water Mark 93 6.11. User calls 93 Oracle Trace Seite 3
rainer@lambertz-c.de 6.12. Execute counts 93 6.13. Distinct keys 94 6.14. Cardinalität 94 6.15. Rule 95 6.16. Choose 97 6.17. Treibende Tabelle 100 6.18. Der Shared Pool Memory 105 6.19. Die SQL Area 106 6.20. Library cache 106 6.21. db file scattered read 107 6.22. db file sequential read 107 6.23. Buffer busy waits 107 6.24. Free buffer waits 108 6.25. Latch free 108 6.26. Log buffer space 109 6.27. Log file switch 109 6.28. Parse 109 6.28.1. Hard Parse 114 6.28.2. Soft Parse 117 7. Index 118 Oracle Trace Seite 4
email: rainer@lambertz-c.de 1. Eine Trace Datei Auch wenn eine Oracleinstanz nur mittelmäßig konfiguriert wurde, sind diese Performance-Verluste geringer als die, welche durch SQL Statements auslöst werden können. Eine Vielzahl an Mißständen kann die Ursache sein. Ohne Hilfsmittel ist es fast ummöglich sie zu finden. Ein Hilfsmittel ist es, während das oder die Statements abgearbeitet werden von Oracle eine Tracedatei erstellen zu lassen In der Trace Datei werden alle Statements protokolliert, welche direkt angegebenen oder durch den Aufruf von Modulen (Packages, Proceduren oder Function) verarbeitet wurden, aber auch solche, welche implizit durch Oracle zur Ausführung gelangten. In einer solchen Datei werden zu jedem Statement zusätzlich Statistiken eingefangen, die für das Tuning von höchster Bedeutung sind. Trace Dateien werden immer im user_dump_dest Verzeichnis der Oracle Instanz erzeugt. Das physikalische Verzeichnis, welches sich hinter dem Alias user_dump_dest verbirgt, kann in der initsid.ora Datei direkt eingesehen werden, oder aber mit einem Select Statemenet ermittelt werden, wie es nachfolgend beschrieben ist. SELECT NAME, VALUE FROM SYS.V_$SYSTEM_PARAMETER WHERE name = 'user_dump_dest' Die Oracle Datenbank besitzt gewöhnlich für dieses Verzeichnis ein Schreibund Leserecht. Der User, welcher die Trace Datei später auswerten möchte verfügt nicht automatisch über diese Rechte! Dies ist gerade für Bertriebsysteme wie Unix zu berücksichtigen. Im Dateinamen einer Tracedatei ist die Session ID enthalten, mit der das Betriebssystem die Session eindeutig verwaltet hat. So ergibt sich als Beispiel eine Datei mit dem Namen ora_488.trc im user_dump_dest Verzeichnis. Das bedeutet, daß die Session (hier SQL*Plus) vom Betriebsystem unter der Nummer 488 geführt wurde. Nur wenn der initsid.ora Parameter TIMED_STATISTICS auf TRUE gesetzt oder die Session entsprechend geändert wurde (ALTER SESSION SET TIMED_STATISTICS=TRUE), entstehen in der Trace Datei zeitliche Statistiken. Ausführungsstatistiken sind in jedem Fall enthalten. Das Erzeugen von zeitlichen Statistiken, also Timed Statistics, führt zu Verlusten zwischen 1% und 5% der CPU Leistung. Zu unterscheiden ist, ob Oracle Trace Seite 5
rainer@lambertz-c.de TIMED_STATISTICS für die gesamte Instanz gilt oder auf eine Session beschränkt ist. In einer Trace Datei können nicht mehrere Sessions protokolliert werden. Es gibt verschiedene Möglichkeiten eine Trace Datei zu erzeugen. Welche das im Einzelnen sind und worin sie sich unterscheiden wird nachfolgend beschrieben. Eine Trace Datei wird erst angelegt, wenn mindestens ein Statement bearbeitet wurde und nicht zu dem Zeitpunkt zu dem der Trace aktiviert wurde. 1.1. Session Trace Ein session trace ist nur für eine Session möglich, wie sie zum Beispiel entsteht, wenn SQL*Plus gestartet wird. Ein solches Programm muß über die Möglichkeit verfügen, die Oracle Session zu verändern (ALTER SESSION...) ALTER SESSION SET SQL_TRACE = TRUE; Der Trace kann jedoch nur eingeschaltet werden, wenn der Oracle User, der mit der Datenbank verbunden ist, über die Berechtigung ALTER SESSION verfügt. Erst wenn der Tracemodus beendet wurde, wird die Tracedatei wieder geschlossen. Entweder durch ein ALTER SESSION Statement wie nachfolgend beschrieben oder durch das Beenden der Session (Disconnect oder Programmende). ALTER SESSION SET SQL_TRACE = FALSE; Wird innerhalb der gleichen Session mehrmals ein Trace ein- und abgeschaltet, werden alle Trace Ergebnisse in der selben Datei gespeichert!! 1.2. Trace einer beliebigen Session Wenn das Einschalten eines Session trace nicht möglich ist (z.b. weil die Verarbeitung schon läuft oder USER X einen Trace für USER Y erstellen möchte), bietet Oracle die Möglichkeit, den Trace mit hilfe einer Procedure eines Package zu starten. Der Aufruf lautet: Oracle Trace Seite 6
sys.dbms_system.set_sql_trace_in_session( SID, serial#, What ); CL ambertz email: rainer@lambertz-c.de Es werden jedoch SID und SERIAL# benötigt, um die Procedure ausführen zu können, die mit folgenden Script ermittelt werden können. Unter dem Einsatz von CUT und PASTE erleichert die Prompt Ausgabe den Aufruf. REM ACCEPT UserName PROMPT 'Name des Oracle Users: '; SELECT osuser, username, status, sid, serial#, Terminal, program FROM v$session WHERE osuser like UPPER( '&UserName' ); PROMPT EXEC sys.dbms_system.set_sql_trace_in_session( SID, serial#, What ); Zu jeder SID, SERIAL# erfolgt noch die Angabe, ob der Trace gestartet (TRUE) oder beendet (FALSE) werden soll. Wird für die gleiche Session (SID und SERIAL#) mehrmals ein Trace ein- und abgeschaltet, werden alle Ergebnisse in der selben Datei gespeichert. Die Art ein Trace zu erzeugen ist auch dann erforderlich, wenn nicht eine gesamte Session, sondern nur ein Ausschnitt der Verarbeitung überwacht werden soll zum Beispiel aus Zeit oder Plattenplatz Gründen. Der User, welche eine fremde Transaktion oder Session tracen möchte, muß über das Ausführungsrecht der Package DBMS_SYSTEM verfügen und zwar als direkten Grant; nicht über eine Role. 1.3. Probleme beim Erstellen einer Trace Datei Werden Trace Dateien aus dem user_dump_dest Verzeichnis gelöscht, ohne daß die Datenbank neu gestartet wird, werden keine neuen Tracefiles erzeugt. Ein EXPLAIN PLAN wird z.b. in einer TKProf Ausgabe Datei nicht erstellt, obwohl die Angabe explain=.. für die Erstellung einer TKProf Ausgabedatei angegeben wurde, wenn die Tabelle PLAN_TABLE für den User, mit dem der Ausführungsplan erstellt werden soll, keine Berechtigung auf diese Tabelle hat, die Tabelle nicht existiert, oder ein anderes Format besitzt, als es von Oracle für die Datenbankversion vorausgesetzt wird. Werden die Anzahl Rows in einer Trace- oder einer TKProf Datei nicht angezeigt, kann es daran liegen, daß ein Trace erzeugt wurde für ein Statement, welche schon über einen längeren Zeitraum lief. Auch ein ALTER SESSION... kann dazu führen, daß für vereinzelte Statements keine Rows angezeigt werden. Werden in mehreren Trace Dateien die Oracle Trace Seite 7
rainer@lambertz-c.de Rows nicht angezeigt, hat sich die Instanz verschluckt und es hilft nur ein reboot. Wurde der Trace noch nicht geschlossen (zum Beispiel ALTER SESSION SET SQL_TRACE = FALSE), werden für die TKProf Datei keine Rows angezeigt. Laufzeit Statistiken (alle zeitlichen Statistiken) werden nicht ermittelt, wenn die überwachte Session im Modus TIMED_STATISTICS=FALSE arbeitet. Eine Trace Datei entsteht nicht zu dem Zeitpunkt, zu dem der Trace eingeschaltet wurde, sondern erst, nachdem das erste Statement ausgeführt wurde. Wird innerhalb einer Session ein Trace mehrmals ein und abgeschaltet, werden die Ergebnisse des Trace in die selbe Datei eingetragen. Es entsteht keine neue Trace Datei. 1.4. Autotrace Autotrace ist eine Low Cost Version an Tuning Informationen zu gelangen unter SQL*Plus. Wesentlicher Unterschied liegt in den fehlenden Statistiken über das Statement. So werden werden nicht die Ausführungsdauer oder die bearbeiteten Rows angezeigt, welche für die Ergebnismenge bearbeitet werden mußten. Ein EXPLAIN PLAN und die Ausführungsstatistiken wie CONSISTENT GETS (gleichbedeutend den Query Werten einer TKProf Datei) sind aber vorhanden. Autotrace wird gestartet in SQL*Plus durch die Eingabe SET AUTOTRACE ON und bleibt solange aktiv, bis der Modus mit SET AUTOTRACE OFF wieder beendet oder die SQL*Plus Session geschlossen wird. Autotrace bewirkt, daß alle eingegebenen Statemets getraced werden und die Trace Ergebnisse direkt nach der Ausführung angezeigt werden. Autotrace liefert nur dann die gwünschten Ergebnisse wenn die Tabelle SYS.PLAN_TABLE existiert und der User über Schreib- und Leserechte für diese Tabelle verfügt. Weitere Berechtigungen, die erforderlich sind, stellt Oracle mit dem Script PLUSTRACE.SQL bereit. Hierbei handelt es sich um die Einrichtung einer Berechtigungsrolle plustrace wie folgt: drop role plustrace; create role plustrace; grant select on v_$sesstat to plustrace; grant select on v_$statname to plustrace; grant select on v_$session to plustrace; Oracle Trace Seite 8
email: rainer@lambertz-c.de grant plustrace to xxxx with admin option; Nachfolgend ein Beispiel für den Einsatz von AUTOTRACE: SQLL > set autotrace on SQLL > select * from dual; D - X 1 row selected. real: 581 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (FULL) OF 'DUAL' Statistics ---------------------------------------------------------- 0 recursive calls 4 db block gets 1 consistent gets 0 physical reads 0 redo size 175 bytes sent via SQL*Net to client 256 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL > set autotrace off; Oracle Trace Seite 9
rainer@lambertz-c.de 2. Trace Datei und TKProf Ausgabe Der Inhalt einer Trace Datei ist nicht zuletzt wegen der Dateigröße sehr schwierig lesbar. Aus diesem Grunde liefert Oracle ein Tool aus, das eine Zusammenfassung aller Informationen aus einer Trace Datei erstellt und in einer beliebig zu benennenden Ausgabe Datei speichert. Aber die Beschreibung der einzelnen Informationen direkt in der Trace Datei ist nicht weniger von Bedeutung als die TKProf Ausgabe. Z.B. sind nur in einer Trace Datei alle Informationen über Ablaufreihenfolgen erkennbar, welche Cursor von welchen abhängig waren, wie groß die Arrays waren die für einen FETCH eines oder mehrerer Statements benutzt wurde und in welcher Häufigkeit der Aufruf des gleichen Statement durch Oracle erfolgt sind. 2.1. Das Trace File im Überblick Mit den ersten Zeilen werden die Randbedingungen beschreiben die vorlagen, als die Trace Datei erstellt wurde. Angaben über den Namen der Tracedatei, über Oracle und die Maschine, auf der die Oracle Instance läuft und die Beschreibung der Instanz selbst. Die Zeile mit der Session ID *** SESSION ID:(9.21) spiegelt die SID und SERIAL# wieder, wie sie auch in der V$SESSON View enthalten sind. Anhand dieser Session ID kann die Trace Datei eindeutig der Session zugeordnet werden, für die ein Trace erzeugt wurde. Nachdem der Name der Application angezeigt wurde, ist der erste Cursor mit PARSING IN CURSOR #1... ausgewiesen. Einige Zeilen weiter -diese werden zu einem späteren Zeitpunkt beschrieben- erscheint das Statement für diesen Cursor, dessen Ende durch END OF STMT angezeigt wird. Mit PARSING IN CURSOR #2 wird der zweite Cursor beschrieben der geöffnet wurde. Das an dieser Stelle die 2 und nicht noch einmal die 1 eingetragen ist, weist darauf hin, daß der erste Cursor noch nicht geschlossen war, als der zweite geöffnet wurde. D.h., immer dann, wenn zum vorherigen Cursor die laufende Nummer um eins erhöht wurde, ist der Cursor mit niedriger Nummer noch nicht geschlossen. Dieses Verhalten kann man recht gut für die beiden Einträge PARSING IN CURSOR #8 in nachfolgenden Tracefile erkennen. Die Höchste Nummer eines Cursor in der gesamten Trace Datei beschreibt, wieviele Cursor maximal zeitglich geöffnet waren. Oracle Trace Seite 10
email: rainer@lambertz-c.de PARSING IN CURSOR #2 zeigt im folgen Auszug einen Cursor, der von Oracle selbst erzeugt wurde. Dump file /oracle/815/admin/orcl/udump/ora_488.trc Oracle8i Enterprise Edition Release 8.1.5.0.2 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production ORACLE_HOME = /oracle/815 System name: Linux Node name: lxnotebook Release: 2.2.13 Version: #3 Tue Mar 14 15:07:16 MET 2000 Machine: i686 Instance name: ORCL Redo thread mounted by this instance: 1 Oracle process number: 8 Unix process pid: 488, image: oracle@lxnotebook (TNS V1-V3) *** 2000.10.31.08.19.10.887 *** SESSION ID:(9.21) 2000.10.31.08.19.10.886 APPNAME mod='sql*plus' mh=3669949024 act='' ah=4029777240 ===================== PARSING IN CURSOR #1 len=52 dep=0 uid=21 oct=47 lid=21 tim=2808754576 hv=4201917273 ad='24442580' begin dbms_output.get_lines(:lines, :numlines); end; END OF STMT PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=0,tim=2808754576 EXEC #1:c=1,e=41,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=2808754617 *** 2000.10.31.08.19.28.354 ===================== PARSING IN CURSOR #2 len=275 dep=1 uid=0 oct=3 lid=0 tim=2808756323 hv=3559516504 ad='2453335c' select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$ from obj$ where owner#=:1 and name=:2 and namespace=:3 and(remoteowner=:4 or remoteowner is null and :4 is null)and(linkname=:5 or linkname is null and :5 is null)and(subname=:6 or subname is null and :6 is null) END OF STMT PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756323 EXEC #2:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756329 FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756329 ===================== PARSING IN CURSOR #3 len=350 dep=1 uid=0 oct=3 lid=0 tim=2808756329 hv=2216582187 ad='245324b0' select ts#,file#,block#,nvl(bobj#,0),nvl(tab#,0),intcols,nvl(clucols,0),audit$,flags,pctfree$, pctused$,initrans,maxtrans,rowcnt,blkcnt,empcnt,avgspc,chncnt,avgrln,analyzetime, samplesize,cols,property,nvl(degree,1),nvl(instances,1),avgspc_flb,flbcnt,kernelcols,nv l(trigflag, 0),nvl(spare1,0),nvl(spare2,0),spare4,nvl(spare3,0) from tab$ where obj#=:1 END OF STMT PARSE #3:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756329 EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756329 FETCH #3:c=0,e=1,p=1,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756330 ===================== PARSING IN CURSOR #4 len=685 dep=1 uid=0 oct=3 lid=0 tim=2808756331 hv=199702406 ad='24531ee4' select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags, i.property,i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey, i.lblkkey,i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#, nvl(i.degree,1),nvl(i.instances,1),i.rowcnt,mod(i.pctthres$,256),i.indmethod#,i.trunccn t,nvl(c.unicols,0),nvl(c.deferrable#+c.valid#,0), nvl(i.spare1,i.intcols),i.spare4,spare2,decode(i.pctthres$,null,null, mod(trunc(i.pctthres$/256),256)) from ind$ i, (select enabled, min(cols) unicols, min(to_number(bitand(defer,1))) deferrable#, min(to_number(bitand(defer,4))) valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where i.obj#=c.enabled(+) and i.bo#=:1 END OF STMT PARSE #4:c=1,e=1,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756331 Oracle Trace Seite 11
rainer@lambertz-c.de EXEC #4:c=1,e=5,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756336 FETCH #4:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756336 ===================== PARSING IN CURSOR #5 len=250 dep=1 uid=0 oct=3 lid=0 tim=2808756336 hv=906438690 ad='2452b92c' select name,intcol#,segcol#,type#,length,nvl(precision#,0),decode(type#,2,nvl(scale,- 127/*MAXSB1MINAL*/),0),null$,fixedstorage,nvl(deflength,0),default$,rowid,col#,property, charsetid,charsetform,spare1,spare2 from col$ where obj#=:1 order by intcol# END OF STMT PARSE #5:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756336 EXEC #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756336 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756336 ===================== PARSING IN CURSOR #6 len=69 dep=1 uid=0 oct=3 lid=0 tim=2808756336 hv=114078687 ad='24543e10' select con#,obj#,rcon#,enabled,nvl(defer,0) from cdef$ where robj#=:1 END OF STMT PARSE #6:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756336 EXEC #6:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756336 FETCH #6:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756336 ===================== PARSING IN CURSOR #7 len=132 dep=1 uid=0 oct=3 lid=0 tim=2808756336 hv=1639440790 ad='24543658' select con#,type#,condlength,intcols,robj#,rcon#,match#,refact,nvl(enabled,0),rowid,cols,nvl(d efer,0),mtime from cdef$ where obj#=:1 END OF STMT PARSE #7:c=1,e=1,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756337 EXEC #7:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756337 FETCH #7:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756337 ===================== PARSING IN CURSOR #8 len=190 dep=1 uid=0 oct=3 lid=0 tim=2808756337 hv=4059714361 ad='2454e914' select type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,nvl(lists,65535),nvl( groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$ where ts#=:1 and file#=:2 and block#=:3 END OF STMT PARSE #8:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756337 EXEC #8:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756337 FETCH #8:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756337 STAT #8 id=1 cnt=1 pid=0 pos=0 obj=14 op='table ACCESS CLUSTER SEG$ ' STAT #8 id=2 cnt=1 pid=1 pos=1 obj=9 op='index UNIQUE SCAN ' ===================== PARSING IN CURSOR #8 len=128 dep=1 uid=0 oct=3 lid=0 tim=2808756339 hv=2554239735 ad='2441ba94' select u.name,o.name from obj$ o,user$ u,trigger$ t where t.baseobject=:1 and t.obj#=o.obj# and o.owner#=u.user# order by o.obj# END OF STMT PARSE #8:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808756339 EXEC #8:c=1,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756340 FETCH #8:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756340 STAT #8 id=1 cnt=0 pid=0 pos=0 obj=0 op='sort ORDER BY ' STAT #8 id=2 cnt=0 pid=1 pos=1 obj=0 op='nested LOOPS ' STAT #8 id=3 cnt=1 pid=2 pos=1 obj=0 op='nested LOOPS ' STAT #8 id=4 cnt=1 pid=3 pos=1 obj=74 op='table ACCESS BY INDEX ROWID TRIGGER$ ' STAT #8 id=5 cnt=1 pid=4 pos=1 obj=119 op='index RANGE SCAN ' STAT #8 id=6 cnt=0 pid=3 pos=2 obj=18 op='table ACCESS BY INDEX ROWID OBJ$ ' STAT #8 id=7 cnt=0 pid=6 pos=1 obj=33 op='index UNIQUE SCAN ' Oracle Trace Seite 12
email: rainer@lambertz-c.de STAT #8 id=8 cnt=0 pid=2 pos=2 obj=22 op='table ACCESS CLUSTER USER$ ' STAT #8 id=9 cnt=0 pid=8 pos=1 obj=11 op='index UNIQUE SCAN ' EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756340 FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756340 EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756340 FETCH #3:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756340 ===================== PARSING IN CURSOR #9 len=190 dep=2 uid=0 oct=3 lid=0 tim=2808756340 hv=4059714361 ad='2454e914' select type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,nvl(lists,65535),nvl( groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$ where ts#=:1 and file#=:2 and block#=:3 END OF STMT PARSE #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756340 EXEC #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756340 FETCH #9:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756340 STAT #8 id=1 cnt=1 pid=0 pos=0 obj=14 op='table ACCESS CLUSTER SEG$ ' STAT #8 id=2 cnt=1 pid=1 pos=1 obj=9 op='index UNIQUE SCAN ' EXEC #4:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 FETCH #4:c=0,e=0,p=0,cr=6,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 ===================== PARSING IN CURSOR #9 len=56 dep=2 uid=0 oct=3 lid=0 tim=2808756342 hv=4195740643 ad='24523c70' select pos#,intcol#,col#,spare1 from icol$ where obj#=:1 END OF STMT PARSE #9:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=0,tim=2808756342 EXEC #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 FETCH #9:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #9:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #9:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 FETCH #4:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 EXEC #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 FETCH #9:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #9:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #9:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 FETCH #4:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 EXEC #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756342 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756343 ===================== PARSING IN CURSOR #10 len=116 dep=2 uid=0 oct=3 lid=0 tim=2808756343 hv=189272129 ad='2452e4dc' select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,o.dataobj#,o.flags from obj$ o where o.obj#=:1 END OF STMT PARSE #10:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=0,tim=2808756343 EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756343 FETCH #10:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 Oracle Trace Seite 13
rainer@lambertz-c.de EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=2808756343 FETCH #10:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=2808756343 ===================== PARSING IN CURSOR #8 len=198 dep=1 uid=0 oct=3 lid=0 tim=2808756343 hv=1854821847 ad='24416dbc' select bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and intcol#=:2 END OF STMT PARSE #8:c=1,e=3,p=1,cr=36,cu=1,mis=1,r=0,dep=1,og=0,tim=2808756343 EXEC #8:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808756343 FETCH #8:c=0,e=1,p=3,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim=2808756344 ===================== PARSING IN CURSOR #1 len=63 dep=0 uid=21 oct=6 lid=21 tim=2808756344 hv=2216434206 ad='2443fc10' update LAMBERTZ.ADRESSEN set name='meier' where name = 'Meier' END OF STMT PARSE #1:c=5,e=21,p=5,cr=58,cu=1,mis=1,r=0,dep=0,og=4,tim=2808756344 *** 2000.10.31.08.19.46.237 EXEC #1:c=440,e=1767,p=15276,cr=15275,cu=1958,mis=0,r=1903,dep=0,og=4,tim=2808758111 STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='update ADRESSEN ' STAT #1 id=2 cnt=1904 pid=1 pos=1 obj=3711 op='table ACCESS FULL ADRESSEN ' ===================== PARSING IN CURSOR #1 len=52 dep=0 uid=21 oct=47 lid=21 tim=2808758187 hv=4201917273 ad='24442580' begin dbms_output.get_lines(:lines, :numlines); end; END OF STMT PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2808758187 EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=2808758187 ===================== PARSING IN CURSOR #1 len=9 dep=0 uid=21 oct=45 lid=21 tim=2808758252 hv=3749013834 ad='2440cf1c' rollback END OF STMT PARSE #1:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=2808758252 XCTEND rlbk=1, rd_only=0 ===================== PARSING IN CURSOR #2 len=275 dep=1 uid=0 oct=3 lid=0 tim=2808758259 hv=570441826 ad='24581ca4' select name,online$,contents$,undofile#,undoblock#,blocksize,dflmaxext,dflinit,dflincr,dflextp ct,dflminext, dflminlen, owner#,scnwrp,scnbas, NVL(pitrscnwrp, 0), NVL(pitrscnbas, 0), dflogging, bitmapped, inc#, flags, plugged, NVL(spare1,0), NVL(spare2,0) from ts$ where ts#=:1 END OF STMT PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=2808758259 EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=2808758259 FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=2808758259 STAT #2 id=1 cnt=1 pid=0 pos=0 obj=16 op='table ACCESS CLUSTER TS$ ' STAT #2 id=2 cnt=1 pid=1 pos=1 obj=7 op='index UNIQUE SCAN ' EXEC #1:c=9,e=142,p=0,cr=22,cu=3830,mis=0,r=0,dep=0,og=4,tim=2808758394 *** 2000.10.31.08.20.02.044 2.1.1. Beschreibung der Ergebnisse in einer Trace Datei Wie im vorherigen Kapitel zu sehen war sind in einer Trace Datei eine Kürzel und Kennungen benutzt worden, die nachfolgend beschrieben werden. PARSE - Statistiken zum erfolgten Parsen Oracle Trace Seite 14
email: rainer@lambertz-c.de EXEC FETCH - Statistiken zu einem INSERT, UPDATE oder DELETE - Statistiken zu einem SELECT Zu jedem einzelnen Vorgang werden aufgelistet: c e p cr cu r CPU Einsatz in 1/100 Sekunden (CPU) Gesamte Verarbeitungzeit in 1/100 Sekunden der entsprechenden Operation (elapsed) Physikalische Disk Zugriffe auf dem Speichermedium (disk) Anzahl Consistent Gets (Query). Anzahl Current Blocks (Current). Anzahl Rows, die eine Operation als Result geliefert hat. Für jedes FETCH werden z.b die Rows angegeben, die mit einem Fetch gelesen werden (Rows). Der Zähler eines Cursors (PARSING IN CURSOR #1) in einem *.trc File wird immer doppelt vergeben, wenn der Cursor geschlossen wurde bevor ein neuer erstellt wird. Für die wiederholte Ausführung folgender Statements select count(*) from adr_name; select count(*) from adr_name; Select count(*) from adr_name; zeigt sich das entsprechende Trace (*.trc) File: ===================== PARSING IN CURSOR #1 len=30 dep=0 uid=21 oct=3 lid=21 tim=2827937218 hv=3851129330 ad='24421058' select count(*) from adr_name END OF STMT PARSE #1:c=6,e=27,p=2,cr=40,cu=0,mis=1,r=0,dep=0,og=4,tim=2827937218 EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2827937223 FETCH #1:c=15,e=121,p=946,cr=945,cu=4,mis=0,r=1,dep=0,og=4,tim=2827937344 STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='sort AGGREGATE ' STAT #1 id=2 cnt=280073 pid=1 pos=1 obj=3717 op='table ACCESS FULL ADR_NAME ' ===================== PARSING IN CURSOR #1 len=30 dep=0 uid=21 oct=3 lid=21 tim=2827937612 hv=3851129330 ad='24421058' select count(*) from adr_name END OF STMT PARSE #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2827937612 EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2827937616 FETCH #1:c=19,e=36,p=0,cr=945,cu=4,mis=0,r=1,dep=0,og=4,tim=2827937652 STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='sort AGGREGATE ' STAT #1 id=2 cnt=280073 pid=1 pos=1 obj=3717 op='table ACCESS FULL ADR_NAME ' Oracle Trace Seite 15
rainer@lambertz-c.de ===================== PARSING IN CURSOR #1 len=30 dep=0 uid=21 oct=3 lid=21 tim=2827938903 hv=2776197289 ad='243fcd50' Select count(*) from adr_name END OF STMT PARSE #1:c=0,e=1,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=2827938903 EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2827938907 FETCH #1:c=18,e=18,p=0,cr=945,cu=4,mis=0,r=1,dep=0,og=4,tim=2827938925 STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='sort AGGREGATE ' STAT #1 id=2 cnt=280073 pid=1 pos=1 obj=3717 op='table ACCESS FULL ADR_NAME' ===================== 2.2. Erstellen einer TKProf Datei Die Übesetzung einer *trc Datei mit dem Tool TKProf erfolgt: tkprof ora_488.trc ora_488.out explain=user/passwort@sid sys=no Es handelt sich um die *trc aus dem vorherigen Kapitel. Somit können Analogien recht gut erkannt werden. Die TKProf Datei hat folgendes Aussehen: TKPROF: Release 8.1.5.0.2 - Production on Tue Oct 31 08:25:18 2000 (c) Copyright 1999 Oracle Corporation. All rights reserved. Trace file: ora_488.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 ******************************************************************************** begin dbms_output.get_lines(:lines, :numlines); end; Parse 2 0.00 0.00 0 0 0 0 Execute 2 0.01 0.41 0 0 0 2 Fetch 0 0.00 0.00 0 0 0 0 total 4 0.01 0.41 0 0 0 2 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ******************************************************************************** update LAMBERTZ.ADRESSEN set name='meier' where Oracle Trace Seite 16
email: rainer@lambertz-c.de name = 'Meier' Parse 1 0.00 0.02 0 58 0 0 Execute 1 4.40 17.67 15276 15275 1958 1903 Fetch 0 0.00 0.00 0 0 0 0 total 2 4.40 17.69 15276 15333 1958 1903 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) Rows Row Source Operation ------- --------------------------------------------------- 1 UPDATE ADRESSEN 1904 TABLE ACCESS FULL ADRESSEN Rows Execution Plan ------- --------------------------------------------------- 0 UPDATE STATEMENT GOAL: CHOOSE 1 UPDATE OF 'ADRESSEN' 1904 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADRESSEN' ******************************************************************************** rollback Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.09 1.42 0 20 3830 0 Fetch 0 0.00 0.00 0 0 0 0 total 2 0.09 1.42 0 20 3830 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ******************************************************************************** begin sys.dbms_system.set_sql_trace_in_session( 9,21,false ); end; Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 0 1 Fetch 0 0.00 0.00 0 0 0 0 total 2 0.00 0.00 0 0 0 1 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ******************************************************************************** OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS Parse 5 0.00 0.02 0 58 0 0 Oracle Trace Seite 17
rainer@lambertz-c.de Execute 5 4.50 19.50 15276 15295 5788 1906 Fetch 0 0.00 0.00 0 0 0 0 total 10 4.50 19.52 15276 15353 5788 1906 Misses in library cache during parse: 4 OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS Parse 13 0.03 0.05 1 30 1 0 Execute 19 0.02 0.12 0 0 0 0 Fetch 54 0.00 0.02 4 60 0 45 total 86 0.05 0.19 5 90 1 45 Misses in library cache during parse: 12 5 user SQL statements in session. 13 internal SQL statements in session. 18 SQL statements in session. 1 statement EXPLAINed in this session. ******************************************************************************** Trace file: ora_488.trc Trace file compatibility: 7.03.02 Sort options: default 1 session in tracefile. 5 user SQL statements in trace file. 13 internal SQL statements in trace file. 18 SQL statements in trace file. 16 unique SQL statements in trace file. 1 SQL statements EXPLAINed using schema: LAMBERTZ.prof$plan_table Default table was used. Table was created. Table was dropped. 207 lines in trace file. 2.3. Interpretieren einer TKProf Datei Auch wenn es sich bei der TKProf Ausgabe Datei um eine Zusammenfassung der Trace Ergebnisse der *trc Datei handelt werden noch recht viele Einzelinformationen geliefert. Trace file: ora_488.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 ******************************************************************************** Oracle Trace Seite 18
email: rainer@lambertz-c.de Im Vorspann der Ausgabe werden die ursprüngliche Trace Datei genannt und das Sortierkriterium, mit welchem die Datei erstellt wurde. 2.3.1. Darstellung der Ergebnisse in einer TKProf Datei Nachdem ein Statement oder der Aufruf einer PL/SQL Routine aufgeführt wurde, erfolgt die Darstellung der Statistik zu dieser SQL Ausführung in Form einer Matrix. Parse 1 0.00 0.02 0 58 0 0 Execute 1 4.40 17.67 15276 15275 1958 1903 Fetch 0 0.00 0.00 0 0 0 0 total 2 4.40 17.69 15276 15333 1958 1903 Die Matrix besteht im Wesentlichen aus den Zeilen Parse, Execute, Fetch und total. Die Spalten zeigen die eigentlichen Statistiken der jeweiligen Operation. Execute Werte fallen nur bei INSERT, UPDATE oder DELETE an und SELECT Statements verursachen Fetch Werte. Grundsätzlich werden drei Arten Operationen unterschieden und protokolliert: Parse Execute entstehen immer bei der Ausführung eines Statement. Die genaue Beschreinbung zum Prase ist dem Anhang zu entnehmen. Werte zeigen die Anzahl der Ausführungen des Statements. Für SELECT Statements kann die Anzahl Execute von der Fetch abweichen. Für explizite Aufrufe ist die Anzahl Parse und Execute identisch. ************************************************************************ SELECT /*+ FIRST_ROWS */ plz.plz, ort.ort FROM ADR_ADRESSEN adr, ADR_NAME name, ADR_Ort ort, ADR_plz plz WHERE name.id = adr.name_id AND plz.id = adr.plz_id AND ort.id = adr.ort_id AND name.name = 'Meier' ------- ------ ------- --------- ------- ---------- ---------- ------- Parse 1 0.01 0.01 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 595 51.60 77.51 14084 3007636 4 1784 Oracle Trace Seite 19
rainer@lambertz-c.de ------- ------ ------- --------- ------- ---------- ---------- ------- total 597 51.61 77.52 14084 3007636 4 1784 ************************************************************************ Für das Beispiel wurde das Statement einmalig in SQL*Plus abgesetzt. Die wiederholte Ausführung des selben Statements, führt zur Verdopplung der count Ergebnisse. ************************************************************************ ------- ------ ------- --------- ------- ---------- ---------- ------- Parse 2... Execute 2... Fetch 1190... ------- ------ ------- --------- ------- ---------- ---------- ------- total 1194... ************************************************************************ Das folgende Beispiel zeigt den Aufruf eines SELECT Statements aus einem Cursor. ************************************************************************ declare v_plz NUMBER( 7 ); begin for cur_rec in( SELECT plz_id FROM adr_adressen WHERE rownum < 21 )loop SELECT plz INTO v_plz FROM adr_plz WHERE id=cur_rec.plz_id; end loop; end; ------- ------ -------- ---------- ------- ------- ---------- -------- Parse 1 0.01 0.01 0 0 0 0 Execute 1 0.00 0.01 0 0 0 1 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ------- ------- ---------- -------- total 2 0.01 0.02 0 0 0 1 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ************************************************************************ SELECT PLZ_ID FROM ADR_ADRESSEN WHERE ROWNUM < 21 ------- ------ ------ --------- ------- -------- ---------- -------- Parse 1 0.00 0.00 0 0 0 0 Oracle Trace Seite 20
email: rainer@lambertz-c.de Execute 1 0.00 0.00 0 0 0 0 Fetch 21 0.00 0.00 0 20 4 20 ------- ------ ------ --------- ------- -------- ---------- -------- total 23 0.00 0.00 0 20 4 20 ************************************************************************ SELECT PLZ FROM ADR_PLZ WHERE ID = :b1 ------- ------ -------- ---------- ------- ------- ---------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 20 0.00 0.00 0 0 0 0 Fetch 20 0.03 0.06 2 40 80 20 ------- ------ -------- ---------- ------- ------- ---------- -------- total 41 0.03 0.06 2 40 80 20 ************************************************************************ Angaben größer 0 (außer der Spalte count) sind auf das Speichern von Zwischenergebnissen in der SGA zurück zu führen. Es werden in der Execute Zeile keine Werte für disk, query, current oder rows angezeigt. Deutlich zu sehen, im folgenden Beispiel für den Einsatz der Funktion MAX. ************************************************************************ SELECT MAX( name ) FROM adr_name ------- ------ -------- ---------- ------- ------- ---------- ------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.01 0 0 0 0 Fetch 1 0.00 0.08 3 3 0 1 ------- ------ -------- ---------- ------- ------- ---------- ------- total 3 0.00 0.09 3 3 0 1 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) Rows Row Source Operation ------- --------------------------------------------------- 1 SORT AGGREGATE 1 INDEX FULL SCAN (MIN/MAX) (object id 7063) ************************************************************************ Ein weiteres Beispiel zeigt, daß Oracle für die Ausführung eines Statement mit einem SubSelect (nicht correlated) eine temporäre Tabelle erstellt. Oracle Trace Seite 21
rainer@lambertz-c.de ************************************************************************ SELECT * FROM adr_adressen WHERE EXISTS( SELECT '#' FROM adr_plz ) ------- ------ ------- ---------- ------- -------- ---------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.01 0 1 4 0 Fetch 32 0.01 0.00 0 32 4 96 ------- ------ ------- ---------- ------- -------- ---------- -------- total 34 0.01 0.01 0 33 8 96 ************************************************************************ Fetch Werte entstehen ausschließlich für SELECT Anforderungen. Also nicht für die Ausführung eines UPDATE, DELETE oder INSERT. Zu jeder einzelnen Operation werden in der Matrix in Spalten aufgelistet: Count Aufzählung, wie häufig eine entsprechende Operation ausgeführt wurde CPU CPU Einsatz in Sekunden. Elapsed Gesamte Verarbeitungzeit der entsprechenden Operation (parse, execute, fetch oder total). Disk Physikalische Zugriffe auf das Speichermedium (Festplatte). Query besitzt die gleiche Bedeutung wie CONSISTENT GETS. Also die Bereitstellung von konsistenten Datenblöcken für die Bearbeitung eines Statements. Die Daten stammen aus dem DB_BUFFER (oder der Festplatte, wenn die Daten schon geflasht wurden) oder als Rollback-Information aus dem Buffer oder von der Festplatte. Query Werte für eine Parse Operation sind auf das Lesen von Data Dictonary Informationen zurückzuführen. Für ein SubSELECT (nicht correlated) innerhalb einer WHERE Klausel (vorausgesetzt ORACLE hat das Statement beim Parse nicht in einen Join überführt) weisen die Spalten Query und Current Werte aus (also nicht nur fetch oder execute ). Ursache ist, daß ORACLE die Ergebnisse des SubSELECT in eine temporäre Tabelle speichert. Hiermit verbunden sind RECURSIVE CALLS. Oracle Trace Seite 22
email: rainer@lambertz-c.de ************************************************************************ SELECT * FROM adr_adressen WHERE EXISTS( SELECT '#' FROM adr_plz ) ------- ------ ------- ---------- ------- -------- ---------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 1 4 0 Fetch 32 0.01 0.00 0 32 4 96 ------- ------ ------- ---------- ------- -------- ---------- -------- total 34 0.01 0.00 0 33 8 96 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) Rows Row Source Operation ------- --------------------------------------------------- 96 FILTER 96 TABLE ACCESS FULL ADR_ADRESSEN 1 TABLE ACCESS FULL ADR_PLZ ************************************************************************ Es gibt Beispiele die zeigen, daß nicht zwingend CONSISTENT GETS für ein Statement entstehen. ************************************************************************ UPDATE ADR_ADRESSEN SET name = Mayer WHERE rowid = :a ------- ------ ------ ---------- ------- ------- ---------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.00 0 0 1 1 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ ------ ---------- ------- ------- ---------- -------- total 2 0.00 0.00 0 0 1 1 ************************************************************************ Für das UPDATE mit der WHERE Klausel auf eine Rowid werden keine query Werte ausgewiesen! Auch für INSERT Operationen werden Query Werte ausgewiesen, die von Oracle für die Suche des nächsten freien Blocks anfallen. Selbst für Tabellen mit mehreren Millionen Datensätzen fällt dieser Wert kleiner 100 aus. Größere Werte weisen auf eine erhöhte Anzahl Extens (>10) hin und ein Reorg der entsprechenden Tabelle sollte angestrebt werden. Current werden beschrieben als CONSISTENT GETS Blöcke, die in den CURRENT Mode (lokal gekapselter Speicher) übernommen wurden, weil Oracle an diesen Blöcken Veränderungen Oracle Trace Seite 23
rainer@lambertz-c.de vorgenommen hat oder neue Blöcke erzeugt wurden. CURRENT Werte treten z.b. auf, wenn durch Datenänderungen Korrekturen an der FREELIST in einem Block erforderlich wurden, oder durch die Reorganisation eines Index (bearbeiten der Header-, Leaf- oder Branch Blöcke eines B*Tree Index - ausgelöst durch INSERTs, UPDATEs oder DELETEs), usw. Current Werte treten aber auch auf, wenn viele Daten geändert oder gelöscht wurden, wodurch das gesamte Datenvolumen innerhalb eines Blocks den definierten PCTUSED unterschreitet. Es erfolgt ein Eintrag in die FREELIST, daß dieser Block wieder für die Aufnahme neuer Daten zur Verfügung steht. Für Änderungen einer Tabelle ohne Indizes liegt der Current Wert bei einem Update unterhalb dem Query Wert. Tabellen mit Indizes weisen grundsätzlich einen größeren Current Wert gegenüber dem Query Wert aus. Aber auch hier gibt es Ausnahmen. UPDATEs, für die keine Zeile zum Aktualisieren gefunden wurde, beträgt der Wert für Execute 0. Somit ist auch ohne einen Execute Plan mit der Angabe von Rows zu erkennen, daß keine Zeile aktualisiert wurde. Für INSERTs hingegen werden keine Current Werte ausgewiesen, wenn für den neuen Wert, der in die Tabelle eingetragen werden soll, das Einsortieren in den Index entfällt und statt dessen die neue Information einfach angehängt wird. CURRENT Werte treten nicht zwingend auf. Rows Anzahl Rows, welche für die einzelne Operation (Parse, Execute oder Fetch) als Ergebnis geliefert wurden. Fällt für die Zeile Fetch die Angabe count kleiner aus als der Wert für die ermittelten Rows, handelt es sich um einen array fetch. Array fetch hat den Vorteil, daß mehere Rows zu einem Paket zusammengafasst und nicht einzeln übertragen werden. ------- ------ ------- --------- ------- ---------- ---------- ------- Parse 1 0.01 0.01 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 595 51.60 77.51 14084 3007636 4 1784 ------- ------ ------- --------- ------- ---------- ---------- ------- total 597 51.61 77.52 14084 3007636 4 1784 Ein Array Fetch kann mit dem OCI (Oracle call interface) programmiert werden. Oracle Tools wie SQL*Plus oder SQL*Forms unterstützen Array fetch von hause aus. Oracle Trace Seite 24
email: rainer@lambertz-c.de Ausgwiesene Rows für einen Explain Plan zeigen die Anzahl Datensätze, welche aus den einzelnen Operationen hervorgingen. Für NESTED LOOPS oder ähnliche Gruppenfunktionen beschreibt die Angabe die Rows, welche aus der Mischoperation für die Weiterverarbeitung geliefert wurden. Hierzu ein Beispiel. Oracle Trace Seite 25
rainer@lambertz-c.de ************************************************************************ SELECT /*+ FIRST_ROWS */ plz.plz, ort.ort FROM ADR_ADRESSEN adr, ADR_NAME name, ADR_Ort ort, ADR_plz plz WHERE name.id = adr.name_id AND plz.id = adr.plz_id AND ort.id = adr.ort_id AND name.name = 'Meier' ------- ------ ------- --------- ------- ---------- ---------- ------- Parse 1 0.01 0.01 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 595 51.60 77.51 14084 3007636 4 1784 ------- ------ ------- --------- ------- ---------- ---------- ------- total 597 51.61 77.52 14084 3007636 4 1784 Misses in library cache during parse: 1 Optimizer goal: FIRST_ROWS Parsing user id: 21 (LAMBERTZ) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: HINT: FIRST_ROWS 1784 NESTED LOOPS 1785 NESTED LOOPS 1785 NESTED LOOPS 1493661 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADR_ADRESSEN' 1495444 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'ADR_NAME' 2987320 INDEX GOAL: ANALYZED (UNIQUE SCAN) OF 'ADR_NAME_ID_IDX' (UNIQUE) 3568 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'ADR_ORT' 3568 INDEX GOAL: ANALYZED (UNIQUE SCAN) OF 'ADR_ORT_ID_IDX' (UNIQUE) 1784 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'ADR_PLZ' 3568 INDEX GOAL: ANALYZED (UNIQUE SCAN) OF 'ADR_PLZ_ID_IDX' (UNIQUE) ************************************************************************ 1785 Row s bilden die Ergebnismenge aus dem ersten NESTED LOOP für die Bedingung name.id = adr.name_id. Auch wenn für die einzelnen Tabellen jeweils rund 1.5 Mio Rows gelesen wurden und den Index fast 3 Mio. Solche Zugriffe sind zu vermeiden. Innerhalb eines Cursors spiegelt die Row Angabe die Anzahl Datensätze wieder, welche für einen Fetch ermittelt wurden. Im folgenden Beispiel wird die Anzahl Rows in der Statistik mit 3 ausgewiesen und im Explain Plan wurde nur eine Row ermittelt, obwohl das Statement nur einmalig ausgeführt wurde. Oracle Trace Seite 26
email: rainer@lambertz-c.de ****************************************************************************** -- Hier der Cursor in einem PL/SQL Block begin for i in( SELECT anrede FROM adr_anrede )loop INSERT into dual values ( '1' ); end loop; end; ------- ------ -------- ---------- ---------- ---------- ---------- ------- Parse 1 0.00 0.00 0 0 0 0 Execute 1 0.00 0.01 0 0 0 1 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ------- total 2 0.00 0.01 0 0 0 1 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ****************************************************************************** SELECT ANREDE FROM ADR_ANREDE ------- ------ -------- ---------- ---------- --------- --------- --------- Parse 1 0.00 0.03 0 3 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 3 0.00 0.04 2 3 9 3 ------- ------ -------- ---------- ---------- --------- --------- --------- total 5 0.00 0.07 2 6 9 3 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) (recursive depth: 1) Rows Execution Plan ------- --------------------------------------------------- 0 SELECT STATEMENT GOAL: CHOOSE 1 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADR_ANREDE' ****************************************************************************** INSERT INTO DUAL VALUES ( '1' ) ------- ------ -------- ---------- -------- --------- ---------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 3 0.00 0.00 0 2 7 3 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- -------- --------- ---------- -------- total 4 0.00 0.00 0 2 7 3 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) (recursive depth: 1) Rows Execution Plan ------- --------------------------------------------------- 0 INSERT STATEMENT GOAL: CHOOSE ****************************************************************************** Oracle Trace Seite 27