Indizes anlegen, hat die Reihenfolge einen Einfluss??

[Peter Schöneich]

Hallo,
ich habe eine Interbase Datenbank, Server Version 6.1.0.6 auf die mit einer Software über die BDE zugegriffen wird.
Aufgrud eines Datenbankdefekts bei einem Kunden (von der DB konnte kein Backup mehr gezogen werden) habe ich die DB neu aufgebaut indem ich die Metadaten mit IBExpert extrahiert und daraus eine neue DB erzeugt habe. Danach habe ich die Daten mit dem Interbase DataPump welches es als Plugin für den IB Expert gibt in die neu erzeugte DB gepumpt. Bis hier hin hat alles super funktioniert.
Im Betrieb gibt es jetzt jedoch ein paar Probleme mit der Datenbank.Zum einen ist die Perfomance an einigen Stellen schlechter geworden und ich hatte auch schon Fehler von der BDE z.B. Fehler 12292 beim anlegen jedes neuen Datensatzes in einer Tabelle.
Nach langem Suchen habe ich jetzt festgestellt, dass die Probleme mit der Reihfolge zu tun haben in der die Indizes erzeugt wurden. Die Performance hat sich nämlich verbessert, nachdem ich gewisse Indices noch mal gelöscht habe und dann in der Reihenfolge angelegt habe, wie sie in der Ursprünglichen Datenbank erzeugt wurden. Ich habe gesehen, dass dieses den Index Plan beeinflusst hat und daß für die gleiche Abfrage ein anderer Index genutzt wurde als vorher obwohl die Indizes ja alle auch vorher
genauso schon da waren. Bei dem BDE Fehler war das ähnlich, nach dem Löschen und Anlegen der Indizes auf der betreffenden Tabelle
ist der nicht mehr vorhanden.
Das ganze kommt mir jetzt natürlich etwas unheimlich vor, weil ich bisher gedacht habe, daß die Reihnenfolge in der man die Indizes anlegt eigentlich egal ist. Evtl. kann mir ja jemand eine plausible Lösung für das Problem geben.

[Thomas Steinmaurer]

Hallo Peter,
<br><br>
ich glaube nicht, dass die Erstellungsreihenfolge Auswirkung haben sollte. Was ich eher vermute ist, dass die Indizes zu einem bestimmten Zeitpunkt nicht mehr ausbalanciert und die Selektivität auch nicht mehr gestimmt hat. Wenn man nun einen Index neu anlegt, dann ist a) der Indexbaum ausbalanciert und b) ist die Selektivität auch aktuell. Vielleicht ist das der Grund, dass der Optimierer einen anderen Zugriffspfad wählt. Obwohl, der Optimierer wurde in Firebird 1.5 und InterBase 7 stark verbessert, d.h. es könnte durchaus sein, dass man auf den einen oder anderen Bug im Optimierer in InterBase 6 trifft.
<br><br>
Thoma

[Peter Schöneich]

Hallo Thomas,
vielen Dank für die schnelle Antwort. So ähnlich hatte ich mir das auch gedacht. Deshalb habe ich auch die Indizes nachdem die Probleme aufgetreten sind im IbExpert als ersten dann noch mal neu aufbereitet, das alleine hat aber noch nichts geholfen. Ich dachte jedoch, die werden dann beim Datenpump ganz neu geschrieben, sprich sollten also aktuell sein?
Ich muss zugeben, dass ich da auch ein kleines Defizit habe, wie Interbase die Indizes aufbaut und wie das mit der Selektivität aussieht. Evtl. kannst Du das noch mal so grob beschreiben, oder vielleicht auch einent Tip geben wo ich da was nachlesen kann wenn man das nicht mit 2-3 Sätzen sagen kann. Das wäre toll.
Ich würde nämlich noch ganz gerne wissen ob es ne andere Möglichkeit gibt, ausser das ich die Indizes auf einer Tabelle komplett lösche - und dann wieder anlege um die beschriebenen Problems zu beseitigen.

Pete

[Thomas Steinmaurer]

Hallo Peter,
<br><br>
weisst Du zufällig welche Operation angestoßen wird, wenn Du sagst Du hast mit IBExpert die Indizes nochmals neu aufbereitet? Wird hier einfach die Selektivität neu berechnet oder wird der Index komplett neu aufgebaut?
<br><br>
Bzgl. Optimierung von InterBase-Anwendungen kann ich Dir diese Artikelreihe empfehlen:
<br>
http://blogs.teamb.com/craigstuntz/articles/IBOptimization1.aspx
<br>
http://blogs.teamb.com/craigstuntz/articles/IBOptimization2.aspx
<br>
http://blogs.teamb.com/craigstuntz/articles/IBOptimization3.aspx
<br><br>
Thoma

[Peter Schöneich]

Hallo Thomas,

danke für die Quellen. Ich habe eben noch mal geschaut, der IBExpert benutzt das SET STATISTICS Kommando, d.h. wenn ich das richtig gelesen habe wird da nur die Selectivität neu berechnet. Um noch mal für zukünfige Probleme vorzubeugen, ist der Weg den ich jetzt beschrieben habe (also aus Metadaten neue DB erzeugt und die Daten dann in die neue DB gepumt) ein legaler Weg oder gibt es da noch bessere Lösungen oder Einwände dagegen.
Ich sollte allerdings noch hinzufügen, daß das Backup an der DB nicht mehr funktioniert hat, lag daran, daß für die vorhandene Pagegrösse(1024) zu viele Generatoren eingefügt waren (D.h. es haben sich Werte einiger Generatoren nicht mehr auslesen lassen). Ich habe also beim Rückspielen der Metadaten die Pagegrösse auf 4096 erhöht und die Generatoren, die nicht mehr lesbar waren von Hand in das Skript eingefügt. Die Generatoren sind zum Glück nirgnds verwendet worden, waren alle ID-Lieferanten für Tabellen, die leer waren. Könnte davon auch noch ein Problem herkommen

[Thomas Steinmaurer]

Hallo Peter,
<br><br>
genau, SET STATISTICS aktualisiert "nur" die Selektivität, baut aber den Index nicht neu auf. Du kannst einen Index mit ALTER INDEX ... deaktivieren und wieder aktivieren, dann wird dieser komplett neu aufgebaut und die Selektivität stimmt auch. Oft bieten irgendwelche Datentransfertools eine Option an, alle Indizes zu deaktivieren, um dann den Datentransfer durchzuführen und anschließend die Indizes wieder zu aktivieren.
<br><br>
Bzgl. Generatoren und Page Size. Ja, das ist ein altes bekanntes Problem. Ich würde Dir so wie so vorschlagen, dass Du immer zumindest eine Page Size von 4096 verwendest, weil dies in der Regel der Größe eines I/O Blocks des Betriebssystems entspricht. D.h., mich würde nicht wundern, wenn Du mit der Vergrößerung der Page Size auch einen Performancegewinn haben wirst.
<br><br>
Thoma