Index statt LF-was bedeutet das?

[deni87991]

Meine Herren, das ist viel Holz für einen Freitag... aber vielen,vielen Danke für eure Auskünfte :-)

Die Sache mit den Zugriffspfaden ect. muß ich noch mal überdenken. Bisher hab ich auch nur einfache LF gemacht, nix kompliziertes oder so.

Werd das jetz mal testen und schaun,was bei rüberkommt.

Wünsche allen ein schönes Wochenende

[Fuerchau]

Aus RPG-Sicht gibt es noch ein paar wesentliche Unterschiede zwischen DDS-LF und SQL-Index:

Ein SQL-Index ist immer eine Only-Index-LF, während eine DDS-LF sowohl Only-Index als auch Index und zusätzliche Felder enthalten kann (nebst berechneten).

Eine SQL-View ist zwar auch eine LF kann jedoch keinen Index enthalten (order by-Klausel).
Dies entspricht dann einer DDS-LF, wenn diese das Schlüsselwort DYNSLT und keinen Key enthält.

Während eine SQL-Join-View keinen Index enthält, kann eine DDS-Join-LF wiederum einen Index enthalten (mit oder ohne DYNSLT).

Leider gibt es in SQL erst seit kurzem die Select-Option "fetch only x rows", die nun dem typischen SETLL/READE-Paar bzw. verkürztem CHAIN entspricht.

Nun zu meinem Vorschlag:
Arbeitet man mit SQL so gibt es nur PF's (ohne Key), Views und Index (neben Prozeduren, die auch Daten liefern können u.v.m.).
Arbeitet man mit RPG/LE-nativen Zugriffen (also CHAIN/READ usw.) sollte man DDS-LF's verwenden um zusätzliche Zugriffe zu sparen.

[deni87991]

Das wirft mir neue Fragen auf:

Was ist eine 'Only-Index-LF'? Heißt das nur 1 Schlüsselfeld oder wie?

Wie gebe ich an ob eine DDS-LF 'Only-Index' oder 'Index + zusätzliche Felder' ist?

Plastisch betrachtet stell ich mir einen Index wie ein Buchindex vor...das ist wahrscheinlich mein Fehler-aber WAS genau ist es denn sonst oder WIE sieht es aus?

Wäre ein View dann vergleichbar mit einem Query? Angucken aber mehr nicht?
Kann ich mit einem Index Sachen berechnen und wieder ausgeben? (also nicht nur stupides angucken wie bei Query)

Eine DDS-LF mit Schlüsselwort DYNSLT und keinen Key hatte ich noch nie-wozu braucht man das?
Meine Kollegen sind leider wenig hilfreich, die sperren sich ziemlich für das Thema.

'Während eine SQL-Join-View' (was ist das?) keinen Index enthält, kann eine DDS-Join-LF(wo brauch man das nun wieder?) wiederum einen Index enthalten (mit oder ohne DYNSLT).

Leider gibt es in SQL erst seit kurzem die Select-Option "fetch only x rows", die nun dem typischen SETLL/READE-Paar bzw. verkürztem CHAIN entspricht.

Leider kann ich deinen Vorschlag nicht wirklich nutzen: ich MUSS SQL nehmen aber sollte mich zuvor erst mal an einer LF probieren (ging ja auch) um dann den Unterschied zu Index rauszufinden.

Gleiches Prinzip wie immer: Keine Ahnung, kaum Hilfe aber "mach mal-probiers halt aus"....super idee,wenn man weder Grundlagen, Aufbau oder Befehle kennt

[Fuerchau]

Wenn du SQL nehmen musst, dann vergiss einfach die DDS !

Per CREATE INDEX beschleunigst du einfach deine Zugriffe, nötig sind sie tatsächlich nicht (beim Update genau eines Satzes aus 1.000.000 kann das dann aber schon mal ein paar Minuten dauern).
Im Index sind Berechnungen nicht möglich.

Per CREATE VIEW kannst du eben "Sichten" incl. Berechnungen über die Daten legen, die die Verarbeitung ggf. vereinfachen.

Ein Select auf einen Index ist nicht möglich, daher kannst du keinen Unterschied zwischen LF und Index per SQL ermitteln.

Ich weiß auch nicht, wozu das nun nötig sein soll.
Wenn du dich mit SQL beschäftigst, dann verwende auch ausschließlich SQL-Methoden (TABLE/INDEX/VIEW). Was die AS/400 dann mit den Objekten treibt ist für die Sache vollkommen unerheblich.
Wichtig sind dann ggf. Joblog-Hinweise (Stichworte STRDBG, QAQQINI) für die Performance.

[jgv]

Birgitta schrieb:

Allerdings sollte man aus Performance-Gesichtspunkten keine DDS beschriebenen logischen Dateien in SQL-Statements verwenden.

Ich greife via JDBC/ODBC mit SQL auf LF's zu. Deshalb würde es mich interessieren zu wissen, warum dies negativen Einfluss auf den Performance hat?

Besten Dank.

jgv

[Fuerchau]

Solange die LF keine eigenständigen Select/Omit's enthält ist dies unerheblich.
SQL geht IMMER über die PF für die Datenzugriffe.
Enthält nun eine LF eigene Select's werden diese aus der LF extrahiert, an den aktuellen Select angehängt und dann auf die PF losgelassen.
Dadurch erklärt sich auch, dass der Zugriffspfad (also Key) einer LF mit Select NIE verwendet werden kann und auch nicht verwendet wird.
Man sollte also zusätzlich immer einen Index anlegen, der der Where- und/oder Order-Klausel entspricht.

Der einzige Grund per SQL auf die LF loszugehen ist eigentlich nur folgender:
Die PF enthält mehrere Mandanten (Firmen o.ä.) und steht in einer Lib, die für Public-zugriffe gesperrt ist.
Die LF's befinden sich in einer eigenen Lib (je Mandant eine) mit einem Select auf den zulässigen Mandanten und Berechtigung für die korrekten User.

Nur dadurch kann gewährleistet werden, dass die Daten eines Mandanten nicht vom anderen geändert/eingesehen werden.
Ein Insert mit dem falschen Mandanten wird allerdings nicht verhindert, das schafft nur ein Trigger.

[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.

[jgv]

Vielen Dank für die rasche Erklärung.

jgv

[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.