1. Eine Trace Datei Session Trace Trace einer beliebigen Session Probleme beim Erstellen einer Trace Datei

Transkript

1 Inhaltsverzeichnis 1. Eine Trace Datei Session Trace Trace einer beliebigen Session Probleme beim Erstellen einer Trace Datei Autotrace 9 2. Trace Datei und TKProf Ausgabe Das Trace File im Überblick Beschreibung der Ergebnisse in einer Trace Datei Erstellen einer TKProf Datei Interpretieren einer TKProf Datei Darstellung der Ergebnisse in einer TKProf Datei Was bildet die Differenz zwischen CPU- und elapsed time So arbeitet Oracle Auflösung eines Statement Der Index Ungünstiger CLUSTERING_INDEX Index Selektivität Verschiedene Indextypen B*tree Index Bitmap Index Hash Index Wann Oracle einen Index im CHOOSE Mode nicht nutzt Zu große Anzahl von gelöscht markierten Indexeinträgen Geringes Datenvolumen der Tabelle Einschränkung mit!= oder <> Unbekannte Selektivität durch Bereichsabfragen Unbekannte Selektivität durch Einsatz von Bindevariablen Unterbrechung der Reihenfolge von Indexattributen Füllgrad des Index-Key Fehlende Statistiken Veraltete Statistiken Abfrage mit IS NULL Abfrage IS NOT NULL Mehrere Indizes Ungünstiger Clustering_Index LIKE in der WHERE Klausel Erklärung eines Explain Plan Operationen eines Explain Plan 66 Oracle Trace Seite 2

2 TABLE ACCESS (FULL) TABLE ACCESS (CLUSTER) TABLE ACCESS (HASH) TABLE ACCESS (BY ROWID) INDEX (RANGE SCAN) INDEX (UNIQUE SCAN) INDEX (FAST FULL SCAN) INDEX (FULL SCAN) INDEX (FULL SCAN (MIN/MAX)) CONNECT BY FILTER MERGE JOIN MERGE JOIN (OUTER) MERGE JOIN (CARTESIAN) SORT (ORDER BY) SORT (JOIN) SORT (AGGREGATE) SORT (UNIQUE) SORT (GROUP BY) NESTED LOOPS (OUTER) NESTED LOOPS (ANTI) NESTED LOOPS (SEMI) CONCATENATION INTERSECTION MINUS UNION UNION-ALL VIEW NESTED LOOPS HASH JOIN INDEX RANGE SCAN Bedeutung von Tabellen und Index Statistiken Glossar Recursive calls DB_BLOCK_SIZE DB_FILE_MULTIBLOCK_READ_COUNT Chained rows Cost DB Block gets DB Block changes Datenblöcke im Überblick Extents High Water Mark User calls 93 Oracle Trace Seite 3

3 Execute counts Distinct keys Cardinalität Rule Choose Treibende Tabelle Der Shared Pool Memory Die SQL Area Library cache db file scattered read db file sequential read Buffer busy waits Free buffer waits Latch free Log buffer space Log file switch Parse Hard Parse Soft Parse Index 118 Oracle Trace Seite 4

4 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

5 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 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

6 sys.dbms_system.set_sql_trace_in_session( SID, serial#, What ); CL ambertz 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 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

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

8 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 SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (FULL) OF 'DUAL' Statistics 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

9 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 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

10 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 Production With the Partitioning and Java options PL/SQL Release Production ORACLE_HOME = /oracle/815 System name: Linux Node name: lxnotebook Release: 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) *** *** SESSION ID:(9.21) APPNAME mod='sql*plus' mh= act='' ah= ===================== PARSING IN CURSOR #1 len=52 dep=0 uid=21 oct=47 lid=21 tim= hv= ad=' ' 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= EXEC #1:c=1,e=41,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim= *** ===================== PARSING IN CURSOR #2 len=275 dep=1 uid=0 oct=3 lid=0 tim= hv= ad=' c' 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= EXEC #2:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim= ===================== PARSING IN CURSOR #3 len=350 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #3:c=0,e=1,p=1,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim= ===================== PARSING IN CURSOR #4 len=685 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= Oracle Trace Seite 11

11 EXEC #4:c=1,e=5,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #4:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,tim= ===================== PARSING IN CURSOR #5 len=250 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=1,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= ===================== PARSING IN CURSOR #6 len=69 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #6:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #6:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim= ===================== PARSING IN CURSOR #7 len=132 dep=1 uid=0 oct=3 lid=0 tim= hv= ad=' ' 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= EXEC #7:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #7:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim= ===================== PARSING IN CURSOR #8 len=190 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #8:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #8:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim= 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= hv= 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= EXEC #8:c=1,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #8:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim= 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

12 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= FETCH #2:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #3:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= ===================== PARSING IN CURSOR #9 len=190 dep=2 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= 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= FETCH #4:c=0,e=0,p=0,cr=6,cu=0,mis=0,r=1,dep=2,og=4,tim= ===================== PARSING IN CURSOR #9 len=56 dep=2 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #4:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= EXEC #9:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #9:c=0,e=0,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #4:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= EXEC #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=4,tim= FETCH #5:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= ===================== PARSING IN CURSOR #10 len=116 dep=2 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #10:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= Oracle Trace Seite 13

13 EXEC #10:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim= FETCH #10:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim= ===================== PARSING IN CURSOR #8 len=198 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #8:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #8:c=0,e=1,p=3,cr=3,cu=0,mis=0,r=1,dep=1,og=4,tim= ===================== PARSING IN CURSOR #1 len=63 dep=0 uid=21 oct=6 lid=21 tim= hv= 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= *** EXEC #1:c=440,e=1767,p=15276,cr=15275,cu=1958,mis=0,r=1903,dep=0,og=4,tim= 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= hv= ad=' ' 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= EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim= ===================== PARSING IN CURSOR #1 len=9 dep=0 uid=21 oct=45 lid=21 tim= hv= 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= XCTEND rlbk=1, rd_only=0 ===================== PARSING IN CURSOR #2 len=275 dep=1 uid=0 oct=3 lid=0 tim= hv= 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= EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim= FETCH #2:c=0,e=0,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim= 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= *** 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

14 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= hv= ad=' ' 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= EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim= FETCH #1:c=15,e=121,p=946,cr=945,cu=4,mis=0,r=1,dep=0,og=4,tim= STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='sort AGGREGATE ' STAT #1 id=2 cnt= 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= hv= ad=' ' 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= EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim= FETCH #1:c=19,e=36,p=0,cr=945,cu=4,mis=0,r=1,dep=0,og=4,tim= STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='sort AGGREGATE ' STAT #1 id=2 cnt= pid=1 pos=1 obj=3717 op='table ACCESS FULL ADR_NAME ' Oracle Trace Seite 15

15 ===================== PARSING IN CURSOR #1 len=30 dep=0 uid=21 oct=3 lid=21 tim= hv= 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= EXEC #1:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim= FETCH #1:c=18,e=18,p=0,cr=945,cu=4,mis=0,r=1,dep=0,og=4,tim= STAT #1 id=1 cnt=1 pid=0 pos=0 obj=0 op='sort AGGREGATE ' STAT #1 id=2 cnt= 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 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 Production on Tue Oct 31 08:25: (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 Execute Fetch total 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

16 name = 'Meier' Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) Rows Row Source Operation UPDATE ADRESSEN 1904 TABLE ACCESS FULL ADRESSEN Rows Execution Plan UPDATE STATEMENT GOAL: CHOOSE 1 UPDATE OF 'ADRESSEN' 1904 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADRESSEN' ******************************************************************************** rollback Parse Execute Fetch total 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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ******************************************************************************** OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS Parse Oracle Trace Seite 17

17 Execute Fetch total Misses in library cache during parse: 4 OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS Parse Execute Fetch total 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: 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 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

18 Im Vorspann der Ausgabe werden die ursprüngliche Trace Datei genannt und das Sortierkriterium, mit welchem die Datei erstellt wurde 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 Execute Fetch total 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 Execute Fetch Oracle Trace Seite 19

19 total ************************************************************************ 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 total ************************************************************************ 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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ************************************************************************ SELECT PLZ_ID FROM ADR_ADRESSEN WHERE ROWNUM < Parse Oracle Trace Seite 20

20 Execute Fetch total ************************************************************************ SELECT PLZ FROM ADR_PLZ WHERE ID = :b Parse Execute Fetch total ************************************************************************ 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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) Rows Row Source Operation 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

21 ************************************************************************ SELECT * FROM adr_adressen WHERE EXISTS( SELECT '#' FROM adr_plz ) Parse Execute Fetch total ************************************************************************ 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

22 ************************************************************************ SELECT * FROM adr_adressen WHERE EXISTS( SELECT '#' FROM adr_plz ) Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) Rows Row Source Operation 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 Execute Fetch total ************************************************************************ 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

23 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 Execute Fetch total 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

24 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

25 ************************************************************************ 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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: FIRST_ROWS Parsing user id: 21 (LAMBERTZ) Rows Execution Plan SELECT STATEMENT GOAL: HINT: FIRST_ROWS 1784 NESTED LOOPS 1785 NESTED LOOPS 1785 NESTED LOOPS TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADR_ADRESSEN' TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'ADR_NAME' 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

26 ****************************************************************************** -- 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 Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) ****************************************************************************** SELECT ANREDE FROM ADR_ANREDE Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) (recursive depth: 1) Rows Execution Plan SELECT STATEMENT GOAL: CHOOSE 1 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'ADR_ANREDE' ****************************************************************************** INSERT INTO DUAL VALUES ( '1' ) Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 21 (LAMBERTZ) (recursive depth: 1) Rows Execution Plan INSERT STATEMENT GOAL: CHOOSE ****************************************************************************** Oracle Trace Seite 27