Database Reference
In-Depth Information
TAL“ der Spaltennamen und als ein Deltawert mit der Endung „_DELTA“ der jeweiligen
Spaltennamen.
Im Statspack-Repository ist die Tabelle STATS$SEG_STAT für die Segment-Statistiken
vorgesehen. Dort werden nur 14 Statistiken in der kumulativen Form gepflegt. Es gibt kei-
ne Deltawerte. Die Segment-Namen und die jeweiligen Objekt-Nummern befinden sich in
der Tabelle STATS$SEG_STAT_OBJ.
Man kann die Segment-Statistiken folgendermaßen beim Performance Tuning benut-
zen:
• dieseStatistikenkönneneineergänzendebzw.eineverifizierendeRollefürdieanderen
Tuning-Methoden spielen. Im Abschn.  12.1 habe ich ein Beispiel erwähnt mit vielen
Updates auf den Tabellen mit Basic Compression. Ich wollte verifizieren, dass diese Up-
dates tatsächlich auf den komprimierten Datenblöcken stattfinden, was zum Entkom-
primieren dieser Datenblöcke und somit zu einem großen Redo-Aufkommen führt. Da
ich vermutet habe, dass viele Chained Rows bei diesem Entkomprimieren entstehen
müssen, habe ich die Statistik CHAIN_ROW_EXCESS ermittelt. Die Statistikwerte wa-
ren sehr groß, was meine Vermutung bestätigt hat,
• ineinigenFällenistessinnvoll,zunächstdieproblematischenSegmentezuermitteln
(z. B. mit vielen Logical Reads), um dann die SQL-Anweisungen zu finden, die die je-
weiligen Tabellen abfragen oder die jeweiligen Indices benutzen. Detailliert ist diese
Methode im Abschn. 17.3 beschrieben.
Mit den Segment-Statistiken muss man etwas vorsichtig sein, da sie täuschen können.
Wenn man eine gravierende Anzahl der Logical oder Physical Reads für einen Index fest-
stellt, heißt es noch lange nicht, dass dieser Index aktiv in den SQL-Anweisungen benutzt
wurde. Es kann sein, dass diese Statistik durch ein DML-Kommando (z.  B. durch einen
Insert) zustande kam, der gar nichts direkt mit unserem Index zu tun hatte. In so einem
Fall kann man vergeblich nach den problematischen SQL-Anweisungen suchen, die diesen
Index benutzen. Die jeweilige Tabelle kommt übrigens auch nicht im Ausführungsplan
dieser SQL-Anweisung vor, obwohl man viele Logical bzw. Physical Reads für diese Tabelle
ermittelt. Das demonstriert das untere Beispiel:
Search WWH ::




Custom Search