Index statt LF-was bedeutet das?

[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

[B.Hauser]

Hallo,

vielfach wird angenommen, dass man den Query Optiomizer dadruch beeinflussen kann, dass man ihm einen "Zugriffs-Weg" sprich DDS-beschriebene logische Datei vorgibt. Das ist jedoch nicht der Fall!

Der Query Optimizer entnimmt aus der logischen Datei nur Informationen über Feld-Auswahl, Join-Bedingungen und Select/Omit-Anweisungen. Mit diesen Informationen wird das SQL-Statement basierend auf den physichen Dateien (Tabellen) neu geschrieben. Anschließend wird der optimale Zugriffs-Weg über alle Zugriffs-Wege (SQL Indices und DDS-beschriebene geschlüsselte logische Dateien) ermittelt. Wird der Zugriffsweg verwendet, der in der ursprünglich angegebenen logischen Datei hinterlegt ist, ist es mehr oder minder Zufall.

Seit drei Releasen gibt es ausserdem zwei Query Engines. Die klassische (classical) Query Engine (CQE) und die neue SQL Query Engine (SQE). Jedes SQL-Statement wird zunächst an den Query Dispatcher geleitet, der entscheidet, welche Query Engine zuständig ist. Die Auflösung der logischen Dateien können nur von der CQE bewerkstelligt werden und es ist meines Wissens auch nicht geplant diese Funktionalität in die SQE aufzunehmen. Es ist nicht nur, dass für die Ausführung des SQL-Statements keine in der SQE implementierte Funktionalität verwendet werden kann
, sondern das Reouting und Verarbeitung durch die CQE kann 10-15% Performance-Einbußen mit sich bringen.

@Fuerchau:

Solange die LF keine eigenständigen Select/Omit's enthält ist dies unerheblich.

Auch dann wird die SQL-Abfrage an die CQE reroutet!

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.

Warum nimmst Du dafür keine View?
Es macht überhaupt keinen Sinn eine DDS-beschriebene logische Datei in einem SQL-Statement zu verwenden.

Arbeitet man mit RPG/LE-nativen Zugriffen (also CHAIN/READ usw.) sollte man DDS-LF's verwenden um zusätzliche Zugriffe zu sparen.

Warum?
Eine geschlüsselte logische Datei (ohne Feldauswahl und select/omit Anweisungen) besteht wie ein SQL-Index aus einem Key-Bereich, in dem die Schlüssel-Werte aufgelistet werden und einer Bitmap. Für jeden (zusammengesetzten) Key ist für jeden Satz der Datei ein Bit hinterlegt, das auf an oder aus steht, je nachdem, ob der Datensatz die Schlüsselwerte hat oder nicht. Über diese Bits und die relativen Adressen werden alle weiteren Informationen für den Datensatz eingelesen.

Bei jedem Chain oder SetLL/Read oder READE wird vom Datenbanken-Manager zunächst QDBGETKY aufgerufen, um den Schlüssel zu verifizieren und anschließend wird über QDBGETSQ der komplette Datensatz eingelesen.

Der Aufruf QDBGETSQ ist notwendig, weil in RPG immer der komplette Datensatz eingelesen wird.

Da spielt es keine Rolle, ob eine DDS beschriebene logische Datei oder ein SQL Index verarbeitet wird.

Im Gegenteil ein SQL-Index ist vorteilhafter, wenn viele Daten geschlüsselt gelesen werden müssen, aufgrund der größeren PageSize.

Bei SQL-Abfragen ist ein Index-Only-Acces (IOA) möglich und zwar dann, wenn alle Informationen, die zur Ausführung des SQL-Statements notwendig sind in den Schlüssel-Werten eines Indices (oder einer geschlüsselten logischen Datei) hinterlegt sind. Dann ist ein Zugriff auf den restlichen Datensatz nicht notwendig.

Beispiel:
Datei: Mandant/BestellNr/Kunde/Liefertermin/AuftragsArt/LieferBedingungen/ usw.
Index: Mandant/Kunde/BestellNr.
SQL-Statement:

Select BestellNr from Datei where Mandant = 10 and Kunde = 1000 

Birgitta

[Fuerchau]

Bezüglich nativem RPG, also ohne SQL egal ob ILE oder nicht:

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.

Und schon sind wir beim Thema "Normalisierung".
Da scheiden sich die Geister z.T. erheblich.
Man nehme am Besten die 5. Normalform (zu jeder Information alle relevanten Schlüssel in genau einer Tabelle).
Wenn ich nun eine Bestellposition mit z.B. 25 Feldern nehme müsste ich also 25 Tabellen mit je 1 Feld und mind. 3 Keys anlegen, was natürlich zu erheblicher Redundanz führt.
Von der Anzahl Zugriffe ganz zu schweigen.

Die Wahrscheinlichkeit eines Index-Only-Zugriffes tendiert daher gegen Null da man meist nur bei der 3. Normalform (gesunde Mischung aus Redundanz und Verteilung) des Datenmodelles bleibt.

Aber was solls, wichtig ist doch nur eins:
Der Kunde wünscht Antwortzeiten unter 1 Sekunde, 3 Sekunden werden ggf. noch akzeptiert.
Wir müssen also alles dafür tun dieses Ziel zu erreichen.

Ich warte diesbezüglich nur auf den 4Terabyte-Stick (wahrscheinlich doch etwas knapp bemessen), da alle beweglichen Teile (sprich Festplatten) dann keine Rolle spielen und endlich Performance keine Rolle mehr spielt.

[holgerscherer]

Ich warte diesbezüglich nur auf den 4Terabyte-Stick (wahrscheinlich doch etwas knapp bemessen), da alle beweglichen Teile (sprich Festplatten) dann keine Rolle spielen und endlich Performance keine Rolle mehr spielt.

Fuerchau, Du weisst, wie lahm Flashmemory ist? Bei der momentanen Entwicklung und den auf dem Markt befindlichen Memorycontrollern (alles Müll) kann man von Glück reden, wenn man irgendwo bei 40MByte/Sek ankommt.

Dann lieber gleich richtiges RAM, was in der Größenordnung noch ein wenig teurer ist und dann auch ein wenig Strom frisst.

Letztlich erreicht man Performance meist besser mit Intelligenz als nur mit einer Hardwareschlacht - ich habe schon Kisten mit 8GB RAM gesehen, die sich hart an der Grenze zu einer kleinen 820er bewegen. Einfach, weil jemand alle Jobs mit gleicher Priorität laufen lässt.

Um den Bezug zu Eurer SQL / Index - Diskussion hinzubekommen: Performance erreicht man mit vielen (intelligent gewählten!) Indizes in Kombination mit einer angemessenen Menge Hauptspeicher. Da haben wir den Systemvorteil vom SLIC (nicht vom i5/OS), dass Hauptspeicher als Readcache für die Platten verwendet wird. Und wie Biggi gewiss antworten wird - durch Nichtverwendung von LFs beim Zugriff via SQL ;-)

-h