Index statt LF-was bedeutet das?

[B.Hauser]

@Fuerchau

Ein SQL-Index enthält doch tatsächlich nur die Felder, die im Index definiert sind.
Benötige ich also eine bestimmte Sortierfolge schaffe ich mir eine LF die sowohl die Schlüssel als auch Nichtschlüsselfelder enthält.
Ein Zugriff aus RPG auf einen SQL-Index macht nur dann Sinn, wenn dieser alle Felder enthält die ich dann auch benötige (siehe auch SQL-Index-Only-Zugriff) ansonsten müsste ich eben auch einen 2. Zugriff durchführen was zu Lasten der Performance geht.

Das ist bereits das zweite Mal, dass Du das verzapfst! Und ich habe Dir schon einmal erklärt, dass dem nicht so ist!

Und ich habe es auch bereits in diesem Thread erklärt, das sowohl geschlüsselte logische Dateien als auch SQL-Indices aus einem Schlüssel-Bereich, in dem alle eindeutigen Schlüssel-Werte aufgelistet sind und einer Bitmap besteht. In Bitmap ist für jeden Satz in jedem Schlüssel ein Bit hinterlegt ist, das auf *ON oder *OFF gesetzt wird, je nach dem, ob der entsprechende Satz zu dem Schlüssel gehört oder nicht. Über die Bitmap Informationen und die relativen Adressen werden die Datensätze eingelesen.

Wenn ein Index nur aus Schlüssel-Werten bestehen würde, wäre es auch SQL nicht möglich Zugriff auf die Datensätze zu erhalten.

Und wenn Du mir immer noch nicht glaubst. Lege Dir eine Datei an (mit DDS oder SQL egal), fülle ein paar Sätze rein. Lege einen SQL Index auf die Datei an (keine DDS beschriebene logische Datei). Anschließend erstellst Du Dir ein kleines RPG Programm und gibst den Index in den F-Bestimmungen an. Mach einen kleinen Chain (mit einem gültigen Schlüssel) auf den Index und zeige Dir mit Dsply einen Feldwert an, dessen Feld nicht im Schlüssel angegeben wurde. Und?

Index-Only-Access hat übrigens nichts mit einer normalisierten Datenbank zu tun! Und auch nichts damit, dass man Single-Key-Indices anlegen müsste.

Ich arbeite mit einer seit 20 Jahren gewachsen Datenbank, die mit Sicherheit alles andere als normalisiert ist, aber dafür viel zu viele Zugriffs-Wege hat.
... und kann in vielen meiner SQL-Abfragen, Index Only-Zugriffe erreichen wobei ich ausserdem immer mit zusammengesetzten Schlüsseln arbeiten muss. Und zwar auch dann, wenn mehrere Dateien verknüpft werden müssen.

Wenn Du allerdings darauf anspielst, dass in normalisierten Datenbanken, die Indices, die beim Joinen verwendet werden keine anderen (Schlüssel-)Felder beinhalten, und dass damit IOA unmöglich ist, ist das auch nur die halbe Wahrheit. Der Optimizer ist in der Lage mit Hilfe von mehreren Indices vorzugsweise EVIs (Index anding/oring)dynamische Bitmaps und andere temporäre Objekte zu bilden. Auch in diesem Fall wäre ein IOA möglich, wenn alle benötigten Informationen in den Schlüssel-Werten (von mehreren Indices) hinterlegt wären. Ausserdem gibt es noch andere Techniken, mit deren Hilfe Zugriffe optimiert werden, wie Star Join-Support in Verbindung mit LPG (Look ahead Predicat Generation).

... und selbst IBM empfiehlt inzwischen einen DBA für die DB2 UDB for iSeries

@ alfredo

Ich bin nicht auf dem neusten Stand.
Aber die neue Such-Engine war am Anfang einWitz.
kein LIKE keine JOINS.
Gerade bei den Joins kommt die alte auf Abwege.
Früher habe ich die Suche mit gezielter Angabe von LF öfter wesentlich beschleunigen können.

Joins werden bereits unter Release V5R2 mit entsprechendem PTF von der SQE bedient. LIKE kann ab Release V5R4 von der SQE bedient werden.

Man kann auch auf die alte Query-Engine Einfluss nehmen, aber nicht dadurch, dass man logische Dateien angibt. (Wenn es geklappt hat, war das auch früher schon Zufall!) Sondern nur dadurch, wie man sein SQL-Statement gestaltet. Wichtig ist, dass man dem Optimizer soviel Information wie möglich gibt. Und zumindest dann, wenn das SQL-Statement mit der CQE ausgeführt wird, sollten Dateien und die zugehörigen Joins in der richtigen Reihenfolge angegeben werden. Zwar sollten beide QEs die Dateien richtig umordnen können, aber sicher ist sicher. Durch die Angabe von OPTIMIZE FOR x ROWS hat man ebenfalls die Möglichkeit auf den Optimizer Einfluss zu nehmen. Bei einer kleinen Anzahl von Zeilen, wird u.U. ein Zugriffs-Pfad verwendet, auch wenn dieser vom Optimizer nur als halboptimal angesehen wird. Bei einer großen Anzahl oder all, wird, sofern nur halboptimale Zugriffs-Wege ermittelt werden, ein Table Scan ausgeführt.

Du wiedersprichst Dir übrigens, denn wird in einem SQL-Statement eine logische Datei angegeben, wird dieses Statement auch unter Release V5R4 über die CQE ausgeführt. Also wenn Du früher durch die Angabe von logischen Dateien Deine Statements beschleunigen konntest, sollte das noch genauso funktionieren. (Aber wie gesagt, das war auch früher schon Zufall)

Woher weißt Du eigentlich, ob Deine Statements mit SQE oder CQE ausgeführt werden?

Birgitta

[alfredo]

Ich habe mir damals das Redbook durchgelesen und da standen alle Ausnahmen, das war dann eigentlich immer.
Das mit den LF war sicher kein Zufall.
Ich verwendete SQL/OPNQRYF für dynamische Abfragen über mehrere Dateien. Da SQL bei seiner Berechnung immer eine Gesamtabfrage kalkuliert und mit den Teilschlüsseln so seine Probleme hat, kam sehr oft die Meldung Zugriff da, aber zu aufwändig. Mit den gezielten LF und den OPTIMIZE for xx rows konnte ich rasche Antwortzeiten erreichen.

[B.Hauser]

OPNQRYF ist überigens kein SQL, sowenig wie QUERY/400. Beides wird wahrscheinlich NIE von der SQE unterstützt.
Wenn Du also nur mit OPNQRYF arbeitest, arbeitest Du immer noch wie vor 10 Jahren, mit CQE!

Birgitta

[alfredo]

hmm... OPTIMIZE for xx rows ist doch SQL?
Wie gesagt traten die Probleme nur bei JOINS(also fast immer) auf, und da war am Anfang nichts mit SQE.

[Fuerchau]

@Birgitta

Bitte >1000Mal um Entschuldigung.
Der Create Index übernimmt ja tatsächlich das Satzformat der PF, sieht also genauso aus wie ein CRTLF, dessen Quelle ausschließlich Key-Definitionen enthält.