Database Reference
In-Depth Information
die Performanz verbessert. Es gibt aber einen Grund, der eventuell noch wichtiger ist. Wenn
auf den jeweiligen Index konkurrierend zugegriffen wird, kann der Umbau dieses Indexes die
Performanz verschlechtern.
“
P.: „
Dieser Index wird nach dem Umbau wesentlich schlanker sein. Das ist doch gut für
die Performanz.
“
L.: „
Erinnerst Du Dich an das Warteereignis
'
latch: cache buffers chains
'
aus dem
Abschn. 3.2.3.8.3? Wenn man die Anzahl der Index-Blöcke reduziert, erhöht sich die poten-
zielle Gefahr der Konkurrenz um diese Blöcke. So können beispielsweise die Wartezustände
für
‚
latch: cache buffers chains
'
entstehen. Statt die Performanz zu verbessern, kann man sie
so verschlechtern.
“
P.: „
Ich muss gestehen, ich bin jetzt ziemlich verunsichert bezüglich des Index-Umbaus.
“
L.: „‚
To rebuild or not to rebuild?' ist keine leichte Frage. Viele Datenbankspezialisten ra-
ten ab den Umbau der Indices vorzunehmen. Ich kenne aber einige Datenbanken, bei denen
ein regelmäßiger Index-Umbau sehr effektiv ist. Wenn man überlegt vorgeht, kann man den
Index-Umbau als Tuning-Maßnahme einsetzen. Ich rate lediglich von unüberlegten und pau-
schalen Lösungen ab.
“
P.: „
Ich verstehe. Hast Du den zweiten Ansatz für die Schätzung der Index-Qualität nicht
vergessen?
“
L.: „
Nein. Dieser Ansatz ist dem bereits Besprochenen sehr ähnlich. Wie ich bereits ge-
sagt habe, besteht der Unterschied darin, dass die Statistiken speziell ermittelt werden. Als
Beispiel des zweiten Ansatzes nehmen wir die Ermittlung dieser Statistiken mit SQL-Anwei-
sungen, bei denen die interne Funktion SYS_OP_LBID für die Berechnung der Anzahl der
Leaf-Blöcke benutzt wird. Dieses Verfahren ist im Skript estimate_sparse_norm_idx10g.sql
implementiert, das die folgenden Parameter hat:
• index_owner.MitdiesemParameterlegtmaneinenSchemanamenfest.Fallsmankeine
Eingabe macht, werden Indices in allen Schemata (außer SYS) geprüft,
• index_name.HierkannmaneinenkonkretenIndex-NameneingebenoderalleIndices
prüfen lassen,
• only_without_stats. Für diesen Parameter kann man 2 Werte eingeben: „Y“ - somit
werden keine Indices geprüft, für die Optimizer-Statistiken erstellt sind, „N“ - bewirkt
die Prüfung unabhängig von der Existenz der Optimizer-Statistiken,
• sample_percent.DieserParameterdefiniertdenProzentsatzderzuprüfendenIndex-
Blöcke und kann die Werte von 1 bis 100 annehmen. Der Vorgabewert ist 10,
• density.WiebeidemSkriptsparse_norm_idx9i.sqlwirddamitdieobereGrenzeder
Index-Dichte als Prozentsatz gesetzt. Der Vorgabewert dieses Parameters beträgt auch
75.
Dieses Skript ist in erster Linie für nicht partitionierte Indices entwickelt worden und berück-
sichtigt nicht alle Besonderheiten dieser Indices. Es zieht beispielsweise physikalische Attribu-
te des ganzen Indexes
(
und keine jeweiligen Attribute der Partitionen bzw. Unterpartitionen
)
bei der Schätzung der Index-Qualität in Betracht.
