LF / SQL index

[woodstock99]

hallo zusammen ,

also ich hab heute den halben Tag rumgespieltund erreicht hab ich nix .
@Fuerchau . hab die LF mit Schlüsselfelder gelöscht und den create Index benützt. Ergebnis -Flasche Datei benützt . ABER er bringt jetzt die Meldung 4 - Also die kosten für die Benützung der Datei sind zu hoch . Das ist der Hit .

@Pickachu . die Felder passen . Order by etc ergebnis - Siehe Fuerchau .
@Birgitta. Nein die Felder sind nicht gleich deshalb kapier ich es ja nicht .
Wie gesagt der Hit ist ja der Advisor bringt immer wieder die logische Datei die ich neu erstellt habe als Vorschlag und er zählt auch fleissig die Times Adviced hoch aber nehmen tut er sie nicht obwohl Sie auf dem System ist .

ICH BIN SCHEINBAR ZU DOOF für diese Datei . Alle anderen klappen .
Kann es sein das zuviele logische drauf sind ? Ich trau es mir kaum sagen aber die Physische Datei hat über 50 logische (Ich hab das nicht verbrochen ) NEIN NEIN NEIN .
Aber dann würde er ja nicht die Meldung 4 bringen mit zu hohen kosten .

Ich forsche da mal weiter bis es klappt . Parole niemals aufgeben oder getreu nach dem Motto Herr vergib ihnen denn sie wissen nicht was sie tun

PS: die logische bezieht sich auf die richtige Physische .....

[Fuerchau]

Zu letztem Kommentar: ohne dem würde die LF in der Liste ja nicht auftauchen.
Ich habe dies auch oft genug erlebt, dass die Vorschläge von der Laufzeit dann nicht genommen werden.
Es wohl so, dass hier 2 IBM-Entwicklergruppen für das Thema zuständig sind so dass das Ergebnis nicht festgelegt werden kann.
Man liest ja immer wieder, das SQL intern den SQL schon mal umbaut. Ich vermute, dass die Indexfindung vor dem Umbau stattfindet und nach dem Umbau der Vorschlag gebracht wird.
Da kommen schon mal Konstrukte wie Index F1/F2 kostet zu viel, bitte mach einen Index F2/F1 und das bei einer Abfrage "... where F1 = X and F2 = Y", ein Drehen der Schlüsselvollkommen sinnlos ist.

Ich hatte mal für eine Anwendung alle SQL's auf V5R4 optimiert. Bei V6R1 liefen sie auch noch performant. Nun bei V7R1 muss ich fast alle SQL's noch mal analysieren da sie nicht mehr performant sind.
Warum die IBM so einen Mist abliefert frage ich mich wirklich.
Gut, einen Vorteil hat das noch, ich werde noch nicht so schnell arbeitslos.

[BenderD]

Ich hatte mal für eine Anwendung alle SQL's auf V5R4 optimiert. Bei V6R1 liefen sie auch noch performant. Nun bei V7R1 muss ich fast alle SQL's noch mal analysieren da sie nicht mehr performant sind.

Dieser Ansatz, SQL Statements so umzubauen, dass sie mit dem vorhandenen Datenbank- und Indexdesign schnell sind, ist Teil des Problems. Die Optimierungen müssen vorrangig am Indexdesign, dann am Datenbankdesign und zuletzt - wenn überhaupt - an der Formulierung bestimmter SQL Statements vorgenommen werden. Wenn zwei verschiedene Beschreibungen derselben Ergebnismenge unterschiedlich schnell ausgeführt werden, dann ist das eher ein Bug als ein Feature der Query Engine - mit der einzigen Ausnahme des optimizing for n rows, das ja die Optimierungsstrategie des Optimizers anspricht. Wenn dann ein Statement auf einen solchen blinden Fleck des Optimizers ausgerichtet wird, dann ist es nur logisch, dass das dann kippt und schlechter wird, wenn der Optimizer besser wird. Chaotisch wurde es dann, als man auf einmal zwei Optimizer hatte, die sich gegenseitig ins Handwerk gepfuscht haben, am Besten hätte man diese Releases komplett übersprungen, wenn man auf SQL setzte.
Ein ähnliches Problem organisiert man sich, wenn man SQL und RLA nebeneinander benutzt, spätestens wenn man bei dem wilden Mix von SQL DDL und DDS landet, der ja sogar von einigen propagiert wird, dann fallen bei der Neuerstellung eines LFs oder eines Index auf einmal ganze Kartenhäuser zusammen, weil das Access path sharing, eine DDS/RLA Altlast, dazu führen kann, dass ein bestimmter Access Path (und den schlägt die QUery engine eigentlich vor) garnicht erstellt wird, wenn man den geforderten Index (nur den kann man erstellen) anlegt. Da braucht man keinen Durcheinander mit CCSIDs und Text-Schlüsselfelder mehr, wenn man den Query Optimizer nicht mehr verstehen will...

D*B

[Pikachu]

Wie sieht denn der SELECT genau aus?

[Fuerchau]

@Dieter
Ich habe meine SQL's nur unwesentlich angepasst sondern halt die benötigten damals vorgeschlagenen Indizes angelegt.
Stand V7R1 ist es nun, dass diese Indizes z.T. nicht mehr verwendet werden und die SQL's deshalb ineffektiv sind. Ggf. hat dies nun damit zu tun, dass die CQE nicht mehr verwendet wird (die meisten Tabellen sind eben noch DDS) und nun die SQE anders optimiert.
Das ist nun einfach blöd und muss man akzeptieren.
Nicht akzeptieren muss man allerdings die geänderten Autocast-Funktionen die zu komplett anderem Verhalten führen bis hin zu falscher Auswahl oder plötzlichen negativen SQLCODE's oder gar positiven SQLCODE's.

[Pikachu]

Hängt die logische auch wirklich an der physischen Datei dran (DSPDBR)?

Aber ohne den echten Aufbau der logischen und physischen Datei und der Abfrage zu kennen, kann man leider nur raten ...

[cbe]

hm, ich verwende bei LFs idR alle Felder und definiere ausschließlich die Keys, also z.B. so

A R FILEL1 PFILE(FILE)
*
A K FELDA
A K FELDB
A K FELDC
*


Keine sonstigen Felddefinitionen und keine Select/Omits.

Mit diesen hatte ich nie ein Problem, dass SQL die nicht verwendet.

[Fuerchau]

Dies ist auch korrekt so, anders funktioniert ein CREATE INDEX auch nicht.
Allerdings kann man nun auch berechnetet Indizes erstellen die dann auch verwendet werden, wenn die Where-Klausel den Ausdruck auch wiederholt. Ist der Ausdruck nicht identisch kann der Index nicht verwendet werden. Daher kann SQL nun auch die Omit/Select's verwenden.
Aber wer denkt schon daran, seinen SQL an so einen Index anzupassen.
Wie viel 100e Indizes soll ich dann erstellen?
Von der Maintenance-Perfomance mal ganz abgesehen.

[woodstock99]

hmmm zu diesem Thema noch eine Frage .
Ich hab ja Indizes angelegt die nicht benützt werden .

Kann mir mal einer folgenden Unterschied noch erklären .


Vorschlag aus Index Advisor genommen und SQL Index erstellt .
Dieser Vorschlag erscheint jetzt nicht mehr in der Liste aber USED DAYS COUNT = 0 und das seit mehreren Tagen . Wenn ich aber den unbenützten Index wieder lösche erscheint er wieder in der Liste.


Anderer Fall . Auch wieder Vorschlag aus Index Advisor genommen und SQL Index erstellt.
Dieser wird wie im Eingangsposting nicht genützt USED DAYS COUNT = 0 aber er erscheint noch unter den Vorschlägen die zuerstellen sind ..



In beiden Fällen . Ich raffs einfach nicht ;(

[andreaspr@aon.at]

Vorschlag aus Index Advisor genommen und SQL Index erstellt .
Dieser Vorschlag erscheint jetzt nicht mehr in der Liste aber USED DAYS COUNT = 0 und das seit mehreren Tagen . Wenn ich aber den unbenützten Index wieder lösche erscheint er wieder in der Liste.

Der Index Advisor gibt nur Vorschläge. Diese Vorschläge sollten immer hinterfragt werden. Da diese Phänome keine Seltenheit sind.
Meine Vermutung ist, dass die DB glaubt, dass dieser Index für bestimmte Abfragen Vorteile haben !könnte!
Da jedoch die statistischen Informationen dazu fehlen (da der Index zu diesem Zeitpunkt nicht existiert), kann eben nur eine Vermutung geäußert werden.
Existiert der Index, startet die DB auch mit der Sammlung statistischer Daten dazu (wieviele eindeutige Werte gibt es, wie oft kommen diese vor, ...)
Anhand dieser Statistik sagt dann der Optimizer: "Hmm ... scheinbar bringt mir der Index doch nicht den erhofften Vorteil ..."

Anderer Fall . Auch wieder Vorschlag aus Index Advisor genommen und SQL Index erstellt.
Dieser wird wie im Eingangsposting nicht genützt USED DAYS COUNT = 0 aber er erscheint noch unter den Vorschlägen die zuerstellen sind ..

Wurde der Eintrag nach dem Erstellen des Index auch aus dem Advisor entfernt?
Er wird nur dann automatisch entfernt, wenn du den Index direkt aus dem Advisor erstellen lässt ... bzg. fragt er dich (glaub ich) ob er ihn aus der Liste entfernen soll.

lg Andreas

[M@tthias]

Hallo woodstock99,

ich erinnere mich an eine Aussage von IBM, dass der Optimizer nicht zwangsläufig alle LFs betrachtet. Da du schreibst, dass es hier über 50 davon gibt, kann es sein, dass deine neue Datei gar nicht "ausprobiert" wird. Das war zumindest die Erklärung eines Consultants, warum wir auch ein solches Verhalten beobachtet hatten. Ich weiß allerdings nicht, wie hoch ein solcher Wert ist oder ob er irgendwo konfigurierbar ist. Falls es deine Umgebung erlaubt und du den Nerv dazu hast, kannst du ja mal ausprobieren, die Anzahl der LFs zu reduzieren... Aber ich kann mich natürlich auch irren.

Viele Grüße
Matthias

[BenderD]

...
die erste Frage, die sich stellt ist: wie wurde der USED DAYS COUNT ermittelt? (DSPOBJD kriegt vieles nicht mit)
die zweite Frage: ist die Information überhaupt richtig? (ich würde dieser Angabe immer nur begrenzt über den Weg trauen)

Für mich ist der entscheidende Punkt: Performance ist messbar!!! Wenn ich einen Index für eine bestimmte Abfrage anlege, dann wird messtechnisch verifiziert ob das einen Effekt hat, wenn nein, dann wird er wieder gelöscht. Der Index Advisor ist für mich immer nur eine zusätzliche Informationsquelle, da gibt es ebensviel Kaffeesatzanteil wie bei dem ganzen CQE/SQE Gesülze, das ist für mich alles J2FtR.

D*B