Begriffserklärung - Lambertz

CL
ambertz
onsulting
Rainer Lambertz, Kreuzstraße 54, 41564 Kaarst,
[email protected]
Begriffserklärung
Buffer gets
zeigt an, wieviele Daten aus dem Buffer für die Bearbeitung des
Statemants eingelesen wurden, um das result set zu ermitteln.
Dieser Wert wird z.B. in SQL*Plus ausgewiesen, wenn
AUTOTRACE eingeschaltet ist. Eine geringe Anzahl Buffer Gets
zeigt, daß nur eine geringe Datenmenge für das Result Set erforderlich war.
Cardinalität
Errechnet sich aus:
Gesamte Anzahl Datensätze einer Tabelle
--------------------------------------------------------------------------------------
DISTINCT_KEYS
Also im besten Fall ergibt sich der Wert 1 und im schlechtesten fall
die Anzahl der Datensätze der Tabelle.
Chained rows
treten auf, wenn bei einem INSERT oder UPDATE der verfügbare
Speicher nicht ausreicht, um die veränderten Daten im gleichen
Block zu speichern. Die Blockgröße ist abhängig von der Definition
DB_BLOCK_SIZE in der initSID.ora Datei. CHAINED ROWS können
häufig vermieden werden, wenn der Wert PCTFREE einer Tabelle
vergrößert wird. Ist ein Datensatz jedoch größer als das gesamte
Block, entsteht immer ein CHAINED ROW.
Beispiel: DB_BLOCK_SIZE ist für die Datenbank mit 4096 (Byte)
eingestellt und für eine Tabelle wurde PCTUSED mit 40 und
PCTFREE mit 10 festgelegt. Somit stehen maximal ca.3686 Bytes
an Speicherplatz für einen Block zur Verfügung. Nun werden drei
Records mit jeweils 1200 Byte in einem Block gespeichert. Erfolgt
ein UPDATE am ersten Datensatz, der um 390 Byte verlängert wird,
________________________________________________________________________________________
Seite 1 von 6
CL
ambertz
onsulting
Rainer Lambertz, Kreuzstraße 54, 41564 Kaarst,
[email protected]
ist der PCTFREE ist mit 410 Bytes groß genug um diese Änderung
im gleichen Block einzutragen. Für das gleiche UPDATE an den beiden anderen Datensätzen reicht der reservierte Platz nicht mehr aus.
Zwei CHAINED ROWS sind entstanden. Wäre PCTFREE mit 30
(1229 Bytes) bestimmt worden, hätte ORACLE nicht drei, sondern
nur zwei Datensätze der Größe 1200 Bytes in dieses Block eingetragen und die Satzerweiterung von gesamt 780 Bytes in dem
PCTFREE aufnehmen können.
Nicht immer kann durch einen vergrößerten Wert PCTFREE ein
CHAINED ROW vermieden werden.
Beispiel: Unter den gleichen Bedigungen wie in der vorherign
Darstellung soll nun ein Datensatz mit der Gesamtlänge von
9870 Byte eingetragen werden. Auch wenn PCTFREE auf 0 gesetzt wäre, reicht der verfügbare Speicherplatz in einem Block
nicht aus den Datensatz zu speichern.
Cost
Diese Maßzahl ist ein theoretischer Wert. Jeder Zugriffsmethode ist
ein Wert zugeordnet. Der schnellste Zugriff ist der auf eine Zeile via
ROWID, wogegen der langsamste ein TABLE ACCESS FULL ist.
Auch ohne genaue Werte zu kennen gilt (theoretisch):
geringe Kosten -
guter Zugriffspfad
hohe Kosten
-
schlechter Zugriffspfad
An diesen Kosten orientiert sich auch der Oracle Optimizer für die
Bestimmung des Explain Plan.
Jedoch gibt es unzählige Beispiele, wo trotz sehr hoher Kosten
eine schnellere Abarbeitung in der Datenbank erfolgt. Also Vorsicht!!
Consistened gets
ist die Maßzahl für verarbeitete Datensätze. Hiezu zählen physikalische Zugriffe genau wie Zugriffe aus der SGA. CONSISTENT
GETS geben in jedem Fall eine Übersicht über den wirklichen
Verlauf der Verarbeitung; im Gegensatz zu COST. Es gilt:
________________________________________________________________________________________
Seite 2 von 6
CL
ambertz
onsulting
Rainer Lambertz, Kreuzstraße 54, 41564 Kaarst,
[email protected]
Db block gets
Geringe Anzahl
-
schnelle Bearbeitung
hohe Anzahl
-
Bearbeitung war aufwendig und zeitkritisch
zeigt die Anzahl Blöcke, die als CONSISTENT GETS in den
CURRENT Mode übertragen wurden.
Db block changes
beschreibt die Anzahl dirty Blocks, welche durch INSERT, DELETE
oder UPDATE in der SGA (DB_BUFFER) verändert wurden.
DB_BLOCK_SIZE
Ist die Blockgröße, in der Oracle seine Daten innerhalb eines Extents und im Speicher verwaltet. Die Blockgröße für Oracle sollte
mit der des Betriebsystems übereinstimmen, da sonst die Anzahl
I/O nicht synchron mit der Oracle Datenverarbeitung erfolgt. Es
entsteht ein Datenüberhang. Die Blockgröße kann nur festgelegt
werden zum Zeitpunkt für den die Datenbank erstellt wird!
DB_FILE_MULTIBLOCK_READ_COUNT
Beschreibt die Anzahl Datenblöcke (er ist in der initSID.ora eingetragen) die für einen einzigen Lesezugriff zusammenhängend
gelesen werden. Diese Angabe wirkt nur für das Lesen von Tabellen. Ausnahme stellt der Index Zugriff "FAST FULL SCAN" dar.
Somit werden für einen Tabellenzugriff immer mehrere Blöcke
gelesen, außer die Tabelle beinhaltet weniger Blöcke als durch
den Parameter DB_FILE_MULTIBLOCK_READ_COUNT beschrieben sind.
Für diesen Parameter gibt es keine allgemeingültigen Richtwert.
Aber wurde er zu gering gewählt, werden wenige Datenblöcke mit
einem Lesezugriff in den Memory gelesen und jede weitere Anforderung führt zu einem I/O und damit im schlechtesten Fall zu
Wartezeiten. Aber auch eine zu großzügige Definition des Parameters DB_FILE_MULTIBLOCK_READ_COUNT kann dazu führen, daß der verfügbare Memory nicht ausreicht die für einen I/O
________________________________________________________________________________________
Seite 3 von 6
CL
ambertz
onsulting
Rainer Lambertz, Kreuzstraße 54, 41564 Kaarst,
[email protected]
gelieferten Datenmengen aufzunehmen. Übermäßiges "flash out"
ist die Folge.
Eine indirekte Aussage, ob dieser Parameter richtig oder falsch
gewählt wurde, ist zu erkennen an dem Wert
DB_FILE_SEQUENTIAL_READ in der View V$?????. Er sagt
aus, wie lange und oft Oracle warten mußte, den angeforderten
Block aus dem Datafile zu erhalten. Mit einem größeren Wert für
DB_FILE_MULTIBLOCK_READ_COUNT werden also mehere
Blöcke direkt in einem Lesevorgang in den DB_BUFFER übertragen. Fordert Oracle in einem CONSISTENT GET einen Block an,
ist es dann wahrscheinlicher, daß der Block schon im Memory
vorhanden ist.
Der Wert für DB_FILE_SEQUENTIAL_READ sollte möglichst 0
sein. In jedem Fall sollte er kleiner werden, wenn
DB_FILE_MULTI_READ_COUNT vergrößert wird.
Distinct Keys
Wird immer nur für einen Index angegeben und zeigt die Anzahl
Datensätze an, die mit einem Index Key erreicht werden können. Der
Wert beträgt für einen primary Key die Anzahl Rows der zugehörigen
Tabelle. Im schlechtesten Fall liegt der Wert bei eins und würde aussagen, daß für einen Index Key alle Sätze der Tabelle angesprochen
würden. Gewöhnlich wird der Wert des DISTINCT KEY jedoch berechnet. Z.B. sind in der Tabelle ADR_ADRESSEN 245591
NAME_ID’s vor:
SQL > select count( distinct name_id ) from adr_adressen;
COUNT(DISTINCT NAME_ID)
---------------------245591
1 row selected.
________________________________________________________________________________________
Seite 4 von 6
CL
ambertz
onsulting
Rainer Lambertz, Kreuzstraße 54, 41564 Kaarst,
[email protected]
Diese Werte werden von Oracle ermittelt, wenn ein Index mit Statistikwerten durch ANALYZE ermittelt wurden. In der View
ALL_INDEXES existiert eine Spalte mit dem Namen
DISTINCT_KEYS, in dem der Wert gespeichert ist. Abweichungen
zwischen dem errechneten Wert und dem Wert, wie er in der View
ALL_INDEXES eingetragen ist, entstehen durch die Art, wie die Statistikwerte ermittelt wurden. Nur mit der ANALYZE Option
COMPUTE liegen keine Abweichungen vor.
Oracle diese Arbeit leisten zu lassen, hat u.a. den Vorteil, daß
DISTINCT_KEYS für Indizes ermittelt werden, die aus mehreren Attributen bestehen.
Extents
Die Anzahl der EXTENTs spiegelt sich in der HIGH WATER
MARK wieder und umgekehrt. Die Anzahl EXTENTs einer Tabelle
verringert sich nicht durch das Löschen von Datensätzen in der
Tabelle, weil Oracle sich an der High Water Mark orientiert. EXTENTs können nicht explizit gelöscht werden, sondern verfallen
durch ein TRUNC auf die entsprechende Tabelle. Die Anzahl der
EXTENTs ergibt sich aus dem größten Datenvolumen, was zu irgend einem Zeitpunkt den Füllstand der Tabelle ausgemacht hat
(HIGH WATER MARK).
Execute Count
Gesamtanzahl aller SQL Aufrufen (User und recursive calls).
High Water Mark
ist eine Maßzahl für den letzten Datenblock einer Tabelle im letzten
Extent in der Datenbank der zu irgend einem Zeitpunkt einmal Daten
beinhaltet hat. Diese Marke wird selbst durch Löschen aller Datensätzen nicht herunter gesetzt, sondern bleibt bis zu einem
TRUNCATE oder DROP der Tabelle bestehen. Bei einen FULL
TABLE ACCESS Zugriff auf Daten einer Tabelle werden alle Blöcke
bis zur HIGH WATER MARK eingelesen; auch wenn sich im Extremfall nicht ein Datensatz in der Tabelle befindet. Die HIGH
________________________________________________________________________________________
Seite 5 von 6
CL
ambertz
onsulting
Rainer Lambertz, Kreuzstraße 54, 41564 Kaarst,
[email protected]
WATER MARK erhöht sich auch, wenn Daten in die Tabelle eingefügt werden und per ROLLBACK wieder entfernt wurden.
Zu beachten ist auch, dass die HIGH WATER MARK extrem in
die Höhe getrieben wird, wenn mehrere Prozesse gleichzeitig in
dieselbe Tabelle schreiben.
Recursive calls
werden z.B. in SQL*Plus angezeigt, wenn vor der Ausführung des
Statements AUTOTRACE ON gesetzt wurde. Recursive calls geben eine Aussage darüber, wie oft Statements implizit ausgeführt
wurden (entweder von Oracle oder Statements aus einer Procedure). Bei diesen Statements handelt es sich DLL Kommandos,
die genau wie alle anderen Statements geparsed werden müssen. Ein praktisches Beispiel für einen recursive call ist die Einbindung eines weiteren Extents. Aber auch, wenn ein Cursor für
ein Statement von Oracle während der Verarbeitung aus dem
Cache entfernt und immer wieder zu Ausführung geladen werden
muß. Auch der Zugriff auf das Data Dictonary äußert sich als recursive call. Die Anzahl der recursive calls sollte nach Möglichkeit
0 sein, wenn keine Proceduren, Funktionen eingesetzt wurden.
Trigger für Datentabellen produzieren auch Recursive Calls.
User Calls
sind Anforderungen durch Oracle dem User Sources bereitzustellen.
User Calls beinhalten Parse und Execute Anforderungen.
________________________________________________________________________________________
Seite 6 von 6