Neuaufbau von Primary Keys

[Martin R.]

Hallo Zusammmen,

ich untersuche gerade Indexes auf ihre Qualität.

Und nun auch schon zu meinen Fragen.
Kann ich PK genauso Reorganisieren(ALTER INDEX <index name> REBUILD ONLINE) wie 'normale' Indexes.

Und macht es bei PKs, von schlechter Qualität, Sinn, diese neuaufzubauen, wenn die Keys lediglich technischer Natur sind. Also in keiner Relation zu anderen Tabellen stehen.

Vielen Dank im Voraus

Viele Grüße

Martin

[dimitri]

ich untersuche gerade Indexes auf ihre Qualität.

Und was genau untersuchst Du da? Ein Rebuild Index ist bis auf einige extreme Fälle unnötig und kostet mehr als er bringt.

Und macht es bei PKs, von schlechter Qualität, Sinn, diese neuaufzubauen

Definiere schlechte Qualität.

Kann ich PK genauso Reorganisieren(ALTER INDEX <index name> REBUILD ONLINE) wie 'normale' Indexes.

Natürlich. Ein PK ist ja auch kein Index, sondern ein Constraint, der u.a. einen Index zum prüfen der Eindeutigkeit verwendet. Somit reorganisierts Du lediglich den zugrundeliegenden Index.

Dim

[Martin R.]

Hallo Dim,

erst einmal vielen Dank.

Zu Deiner Frage

ich schau, ob

ROUND((SUM(TC.AVG_COL_LEN + 1) + 7) * I.NUM_ROWS /
(I.LEAF_BLOCKS * (8192 -100 - 23 * NVL(I.INI_TRANS, 2)) *
(1 - NVL(I.PCT_FREE, 10) / 100)) * 100, 0)

FROM user_INDEXES I,
user_IND_COLUMNS IC,

<75 ist

Bei den PKs habe ich mich missverständlich ausgedrückt.
Wie Du schon geschrieben hast meint ich den zu prüfenden Index eines PKs

Auf einer Testmaschiene habe ich einen Index neu aufgebaut
vorher > 3 GB nacher 0,75. Nach meiner Rechnung hatte er vorher eine 'Qualität' von 4 und nacher 87

Viele Grüße

Martin

[Martin R.]

Edit

Ist es Deiner Meinung nach Sinnvoll, nach diesen o.a. Kriterien die Indexes zu qualifizieren.

Habe es so gelesen

[dimitri]

Habe es so gelesen

Lass mich raten? Don Burleson?

Ist es Deiner Meinung nach Sinnvoll, nach diesen o.a. Kriterien die Indexes zu qualifizieren.

Das kommt darauf an. Wurde die Tabelle zu einem großen Teil geleert und werden diese Daten auch nicht wieder befüllt, kann es sinvoll sein den Index neu aufzubauen, wenn hauptsächlich per Index fast Full Scan darauf zugegriffen wird oder wenn der Plattenplatz sehr limitiert ist.
Werden hauptsächlich Range Scans auf dem Index gemacht, kann es vorher wie nachher keinen Unterschied im Zugriff machen.
Werden die Daten in die Tabelle wieder eingefügt, benutzt Oracle den freien Platz natürlich wieder sofern dies möglich ist. Ist zwischen 3 und 10 Platz auf den Leave Pages, dann können neue Daten eingefügt werden ohne das neuer Platz angefordert werden muss. 11 passt natürlich nicht mehr in diese Lücke. Das ganze mal als grobes Beispiel.

Hast Du so einen Index neu aufgebaut, dann muss Oracle hier den Platz den Du vorher freigegeben hast wieder neu anfordern, Blöcke splitten, jede Menge Redo schreiben etc. Dann kann der Reorg also durchaus auch einen negativen Effekt haben.

Bevor man im großen Stil also Indices neu aufbaut sollte man sich überlegen, ob a) überhaupt ein Performanceproblem besteht welches dadurch behoben werden kann und b) ob ich die Zeit nicht besser ins SQL Applikationtuning stecke.

Ich geb allerdings zu, dass es schon Spass macht anhand solcher SQLs (die man auch nicht immer ganz versteht ) ein bissl rumzufuhrwerken und die CPU rauchen zu lassen Sinnvol ist es meistens nicht.

Auf jeden Fall würde ich protokollieren, wieviel Platz die Indices heute belegen und wieviel sie in einem Monat haben. Sind sie bis dahin wieder auf die alte Größe gewachsen, wär es kontraproduktiv das ganze zu wiederholen.

Dim

[MPr]

zum Thema Index Rebuild (und Mr. Burleson) könnte man vermutlich ganze Bücher füllen. Bei Tom Kyte findet man z.B. einen lesenswerten (aber sehr langen) Thread zum Thema "Index Rebuild". Daneben haben sich vor allem Jonathan Lewis und Richard Foote um allerlei Richtigstellung bemüht. Mr. Burleson behauptet in seiner "Definitiven Referenz" (zu der Charles Hooper eine lesenswerte Rezension geliefert hat), dass der Placebo-Effekt für die Endanwender das Index-Rebuilding selbst dann rechtfertigen würde, wenn jemand beweisen könnte, dass es völlig nutzlos ist, was Jonathan Lewis mit folgendem schönen Kommentar versehen hat: "If the only effect is a placebo effect couldn’t you just tell the users that you had rebuilt the indexes rather than actually doing it ?"

Gruß

MP

[Martin R.]

Hallo Dim,

vielen DAnk für Deine Hilfe!

Lass mich raten? Don Burleson?

Naja, da kanns auch einer gleich einem bayrischen Adligen gesehen haben

Das kommt darauf an. Wurde die Tabelle zu einem großen Teil geleert und werden diese Daten auch nicht wieder befüllt, kann es sinvoll sein den Index neu aufzubauen, wenn hauptsächlich per Index fast Full Scan darauf zugegriffen wird oder wenn der Plattenplatz sehr limitiert ist.
Werden hauptsächlich Range Scans auf dem Index gemacht, kann es vorher wie nachher keinen Unterschied im Zugriff machen.
Werden die Daten in die Tabelle wieder eingefügt, benutzt Oracle den freien Platz natürlich wieder sofern dies möglich ist. Ist zwischen 3 und 10 Platz auf den Leave Pages, dann können neue Daten eingefügt werden ohne das neuer Platz angefordert werden muss. 11 passt natürlich nicht mehr in diese Lücke. Das ganze mal als grobes Beispiel.

Hast Du so einen Index neu aufgebaut, dann muss Oracle hier den Platz den Du vorher freigegeben hast wieder neu anfordern, Blöcke splitten, jede Menge Redo schreiben etc. Dann kann der Reorg also durchaus auch einen negativen Effekt haben.

Bevor man im großen Stil also Indices neu aufbaut sollte man sich überlegen, ob a) überhaupt ein Performanceproblem besteht welches dadurch behoben werden kann und b) ob ich die Zeit nicht besser ins SQL Applikationtuning stecke.

Ich geb allerdings zu, dass es schon Spass macht anhand solcher SQLs (die man auch nicht immer ganz versteht ) ein bissl rumzufuhrwerken und die CPU rauchen zu lassen Sinnvol ist es meistens nicht.

Auf jeden Fall würde ich protokollieren, wieviel Platz die Indices heute belegen und wieviel sie in einem Monat haben. Sind sie bis dahin wieder auf die alte Größe gewachsen, wär es kontraproduktiv das ganze zu wiederholen.

Dim

Der Index ist inzwischen wieder auf 1,4 GB angewachsen.
Theoretisch werden pro Tag je nach Kalendervortschritt im Quartal von ca 20.000 linear anwachsend bis ca. 1 Mio Daten upgedatet.
Insgesam sind es ca. 30.Mio DS vorhanden.
Der Inhalt sind Ergebnisse von Regelwerksprüfungen.
In 99% der Fälle ändert sich nur das Datum.
Dieses Datum ist in Verbindung mit einem Regelkuezel auch indiziert.

In der Tabelle wird dann quasi protokolliert: was,Datum der letzten Prüfung,welche Regel und das ergebnis(positiv/negativ).

Die Daten werden dann von Sachbearbeitern benötigt, also Performace ist wichtig

Nochmals vielen Dank, natürlich auch Dir MP

Viele Grüße

Martin