View Full Version : empfolene Indices
Hi *all
ich habe hier eine komplexe view auf zusammen 6 Dateien.
Die Dateien haben zwischen 3 und 15 Mio Datensätze.
Wenn ich nun einen select auf die View mit group mache, sagt mir das Joblog die empfolenen keys.
Was mich wundert ist.
Es gibt ein LF mit key1, key2, key3, die Empfehlung ist key3, key2, key1 , also genau umgekehrt.
Diese Empfehlung kommt nicht aus einem von mir vergebenen Order BY sondern aus den Verknüpfungen. (fast) Alle Dateien haben diesen key1, 2 und 3, (fast) jede Empfehlung ist 3, 2, 1.
Das hatte ich noch nie.
hat jemand eine Erklärung?
Danke
Gruß
Robi
Ich hab die view source kopiert und die verknüpfungen gedreht.
vorher
a.key1 = b. key1 and a.key2 = b.key2 and a.key3 = b.key3
jetzt
a.key3 = b. key3 and a.key2 = b.key2 and a.key1 = b.key1
aber das hat NIX gebracht, empfehlung nach wie vor genau andersrum als es die LF's gibt
Robi
andreaspr@aon.at
27-02-13, 09:56
Das kann durchaus Sinn machen.
Nehmen wir an die Häufigkeit der Keyfelder sieht wie folgt aus:
key1 = 50%
key2 = 35%
key3 = 15%
Dann wäre es sinnvoll einen Index zu haben wo zuerst mal mit key3 mit 15% der Sätze gesucht werden.
Also der Key wo am wenigsten Treffer vorhanden ist.
Reihenfolge: key3, key2, key1
Bei 10 Mio Sätzen werden also zunächst mal nur 1,5 Mio gelesen.
Mit key2 und key1 werden dann die restlichen aussortiert.
Reihenfolge: key1, key2, key3
Da würden zuerst schon mal 5 Mio gelesen werden, da key1 50% aller Sätze beinhaltet.
Dann erst werden die restlichen aussortiert.
Das ist jedoch nur eine Vermutung. Da ich weder weiß wie das gesamte SQL aussieht noch wie der innhalt der Tabellen aufgeteilt ist.
lg Andreas
andreaspr@aon.at
27-02-13, 10:01
Man sollte auch nicht vergessen dass es NUR eine Empfehlung ist.
Es kann sein, dass diese Empfehlung keine Auswirkung hat wenn du den Index entsprechend erstellst.
Nur wenn die DB auch einen MTI (temporären Index) erstellt, dann hat die "Empfehlung" wirklich hohes Gewicht.
Ansonsten ist es besser wenn man die Datenbank und den Inhalt der Tabellen entsprechend Analysiert und darauf aufbauend seine Indexstrategie wählt.
Je nach dem um was für Daten es sich handelt und wie oft die Tabelle bearbeitet wird (INSERT, DELETE, UPDATE) könnte ein EVI Index oder eine MQT besser sein.
Hallo Andreas,
die vermutung ist gut, solche gedanken habe im mir noch nicht gemacht.
Leider trifft die Vermutung hier nicht zu,
Alle Keys sind Numerisch
Fall1
key1 ist 7 stellig und fast unique
key2 ist 2 stellig, selten gefüllt (25 - 30 %) und
key3 ist 2 stellig und IMMER 0
Genauso bei den anderen verdrehten Vorschlägen
Fall2
key1 7 stellig, fast unique, (andere Bedeutung als oben)
key2 1 stellig immer gefüllt, nur 1, 2 oder 3
und
Fall3
key1 7 stellig fast uniqe
key2 3 stlellig, fast immer 0
noch ne Idee?
( der select mit Group läuft schon seit 2,5 Stunden)
Robi
Auf den Betroffenen dateien liegen schon unmengen an indexen, leider viele 'doppelt' dafür mit select oder ommit.
Die von mir erwähnten Indexe sind aber in der PF und somit ohne select/ommit
EVI geht hier gar nicht, zu viele Änderungen, was meinst du mit MQT?
Robi
Könnte auch sein dass die Größe der Felder eine Auswirkung hat.
Key 1 ist ja größer. da möchte er vielleicht zuletzt suchen weil er länger braucht.
Außerdem möchte er vielleicht bestimme casts aus der Abfrage so selten wie möglich ausführen.
MQTs sind quasi physische views auf mehrere Tabellen. Sie updaten sich je nach einstellungen entweder zu einem bestimmten Zeitpunkt oder immer sobald sich eine der Tabellen ändert.
Vorteil: Bei abfragen schneller, da das select auf mehrere Tabellen nicht neu ausgeführt werden muss.
Nachteil: Verbrauchen natürlich Speicher.
... meine Glaskugel ist gerade defekt und Kaffeesatz habe ich auch gerade keinen zur Hand. Aus dem hohlen Bauch:
- erst mal alle Debug Messages durcharbeiten, was ihr an den vorhandenen Indexen nicht schmeckt.
- zuweilen kann ein Order by ihr auf die Sprünge helfen
- ausprobieren, was sie mit den vorgeschlagenen Indexen hinkriegt (oder ob sie sich für ein anderes Paar Schuhe entscheidet...)
D*B
PS: EVIs sind für join und group by (wie in den meisten anderen Fällen) völlig nutzlos - ein typisches Gag Feature des Marketings.
andreaspr@aon.at
27-02-13, 10:40
Man(n) müsste sich den Zugriffsplan anschauen den die DB derzeit verwendet.
Du kannst dir im Navigator mit Rechts-Klick auf "Datenbanken" den Job anschauen der die Abfrage durchführt --> dann Details --> und auf Visual Explain.
Dann könntest du vielleicht erkennen warum er diese Reihenfolge vorschlägt.
Alles was > ein paar Sekunden und überhaupt bei über 1 Stunde braucht, liegt das Problem entweder an der Abfrage selbst.
Oder an gewissen Datenbankeinstellungen (SRTSEQ=*HEX?, QAQQINI, Logische File im FROM statt Phyische usw.)
Und was MQTs betrifft ist es so wie Obv gesagt hat.
Nur dass es derzeit auf der IBM i noch nicht möglich ist ein automatisches Refresh zu machen. Das gibt es nur bei DB2 LUW.
MQTs sind optimal, wenn die benötigten Daten auch ein paar Stunden oder Minuten alt sein dürfen.
Du kannst sie sowohl über eine als auch mehrere Tabellen anlegen.
Damit verlagerst du die Zeit für das Sammeln der Daten auf einen eigenen JOB der je nach Interval die Vorselektion startet.