Database Reference
In-Depth Information
SQL> select /*+ index(t1 i_t1) */ count(*) from test1.t1 where a between 1 and 100000;
COUNT(*)
----------
2
SQL> select plan_table_output from table (sys.dbms_xplan.display_cursor('','','ALLSTATS
LAST'));
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------
------------------
SQL_ID axhasfhd10093, child number 0
-------------------------------------
select /*+ index(t1 i_t1) */ count(*) from test1.t1 where a between 1
and 100000
Plan hash value: 3547404373
------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 428 |
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.01 | 428 |
|* 2 | INDEX RANGE SCAN| I_T1 | 1 | 2 | 2 |00:00:00.01 | 428 |
------------------------------------------------------------------------------------
P.: „
Ich kehre zurück zu meiner Frage. Ist es möglich, die Qualität eines Indexes zu schätzen?
“
L.: „
Das ist möglich, Peter. Dafür gibt es 2 verschiedene Ansätze. Bei einem werden die
vorhandenen Optimizer-Statistiken benutzt, bei dem anderen werden diese statistischen In-
formationen speziell für die Schätzung der Index-Qualität ermittelt. Die Methoden, die auf
dem ersten Ansatz beruhen, sind wesentlich schneller als diejenigen, die den zweiten Ansatz
benutzen.
“
P.: „
Wozu dient dann der zweite Ansatz?
“
L.: „
Möglicherweise fehlen die Optimizer-Statistiken für die jeweilige Tabelle bzw. für den
jeweiligen Index. Es gibt aber noch einen Grund. Meiner Meinung nach ist der zweite Ansatz
präziser als der erste. Die Genauigkeit der Schätzung der Index-Qualität nach dem ersten
Ansatz ist stark von der Genauigkeit der vorhandenen Optimizer-Statistiken abhängig. Wenn
man diese Statistiken selber ermittelt, kann man deren Genauigkeit auch bestimmen
(
bei-
spielsweise ermitteln sie für alle Datensätze statt für einen Prozentsatz
)
. Noch ein Beispiel:
Die durchschnittlichen Längen der Index-Spalten, welche mit dem Package DBMS_STATS
berechnet werden, sind auf Ganzzahl abgerundet. Wenn die Werte der Index-Spalten von
geringer Länge sind, führt es zu einem spürbaren Präzisionsverlust bei der Schätzung der
Index-Qualität. Die Ermittlung dieser Längen
'
per Hand
'
kann ohne Abrundung erfolgen
.
Fangen wir mit dem ersten Ansatz an. Steve Adams hat diesen Ansatz im Skript sparse_in-
dexes.sql in
[
14
]
implementiert. Dieses Skript berechnet die optimale Anzahl der Leaf-Blöcke
der Indices und berücksichtigt dabei die physikalischen Attribute des Indexes wie INITRANS
und PCTINCREASE. Das Skript sparse_norm_idx9i.sql benutzt dasselbe Prinzip, ist aber
etwas weiterentwickelt. Die Ausgabe dieses Skripts sieht folgendermaßen aus:
“
