View Full Version : Optimale SQL Indexe
Hallo Fuerchau,
Mit "Visual Explain" -> "Ausführen und mit Explain bearbeiten" haben wir das bisher gemacht.
Anzeigen empfohlener Indexes aktiviert und einfach alle Indexe erstellt die empfohlen wurden.
Auch wenn es in vielen Fällen hilfreich war bezweifle ich ob das wirklich die richtige vorgehensweise ist.
Ausserdem hat es nicht immer geholfen und hat auch dazu geführt das wir jede Menge Indexe haben wo keiner genau weiß ob die wirklich etwas bringen.
lg Michael
Vielleicht noch eine kurze Erklärung warum das derzeit für mich wichtig ist.
Wir arbeiten gerade an einem ERP Upgrade. Dadurch ändern sich die verwendeten Biliotheken (Schemas) und in vielen Fällen auch die Tabellen bzw. deren Felder.
Das führt dazu das wir so ziemlich alle WebQuery Reports, bzw. die SQL-Views die dafür verwendet werden, überarbeiten bzw. anpassen müssen. (und das sind wirklich viele)
Wenn wir schon fast alles "neu" machen dann möchte ich es soweit möglich auch verbessern.
Es gibt schon jetzt SQL-Views die für WebQuery eine zu lange laufzeit haben (führt im WebQuery zu timeouts), daher werden die Ergebnisse dieser Views in Nacht-Jobs mittels Prozeduren in Tabellen gespeichert und diese dann für die Auswertungen verwendet. Aber das lässt sich wegen untershiedlicher Anforderungen nicht immer machen.
lg michael
... aus meiner praktischen Erfahrung gibt es da ein paar Grundregeln:
- Anforderungsanalyse: Was darf wie lange dauern.
- den (eigenen und maschinellen) Aufwand begrenzen auf das, was die Anforderungen nicht erreicht.
- Laufzeiten messen statt schätzen oder schätzen lassen (STRDBMON ist Dein Freund)
- bei Verbesserungsversuchen kann man sich durchaus von Empfehlungen der Query Engine leiten lassen
- nach Verbesserungsversuchen neu messen, falls es nix bringt Rückbau auf Stand vorher
Von Blindschusstherapien rate ich ab, anlegen überflüssiger Indexe kann drastische Folgen haben und freut allenfalls den Hardware Lieferanten.
D*B
Nun ja BI ist schon immer eine Kunst, deshalb habe ich mich dieser auch verschrieben (siehe Signatur).
Was den Querytimeout angeht, so kann man diesen via QAQQINI überschreiben.
Dein bisheriges Vorgehen hat sich auch heute noch nicht geändert.
Um zu prüfen, welche Indizes tatsächlich verwendet werden, kann man leicht an Hand der geöffneten Dateien des Jobs sehen. Auch unter STRDBG (gibt auch einen QAQQINI-Eintrag dafür) muss man sich die Meldungen im Joblog ansehen. Für jede Datei gibt es 1-2 Einträge in der die Indizes mit einem Bewertungscode aufgeführt sind. Der Index mit Bewertung 0 wurde verwendet.
Im Gegensatz zu früher hat sich auch der Einsatz von 1-Feld-Indizes verbessert, da der Optimizer durchaus in der Lage ist, Indizes zu kombinieren. Also an Stelle viele Indizes mit wilden Feldkombinationen (A+B, A+C, B+C+D, ...) zu erstellen reicht es durchaus, weniger Indizes mit genau nur 1 Feld zu verwenden. Das dient dann auch der Pflegeoptimierung.
Dabei wird man dann feststellen, dass es durchaus Felder gibt, die nur weniger als 10 verschiedene Werte aufweisen und dann ein Tablescan effektiver sein kann.
Und da kommt dann nun wirklich EVI ins Spiel, da hier die Bitmap/RRN-Kombinationen extrem eine Rolle spielen. Wichtig ist bei der Erstellung die "Anzahl Distinct Values" fest zu legen um einen Rebuild zu verhindern.
Nachzulesen in Birgittas o.a. Link;-).
Nachtrag:
Und was Birgittas Hinweis angeht, bereits Aggregate in den EVI zu schieben, so ist dieser wenig zielführend. Wie man an Hand der Beschreibung sieht, wird das Aggregat zum Schlüssel gebildet.
In einer mandantenfähigen Software kommt man bei Aggregaten selten ohne Where-Klauseln aus, sowie bei Gruppierungen über mehr als 1 Feld, da sind dann die voraggregierten Werte eher sinnlos.
Ich danke euch vorerst mal für eure Antworten. Ich muss mir jetzt erst mal die empfohlene Literatur durchlesen und ein paar tests mit den vorgeschlagenen tools durchführen.
Da ich auch verpflichtet worden bin meinen Urlaub abzubauen (da hat sich einiges angesammelt) könnte es ein paar Wochen dauern.
Trotzdem - Vielen Dank vorerst