View vs LF / Performance

[B.Hauser]

@Birgitta
Da die voll dynamischen SQL's auf die VIEW gehen, würden diese also an die CQE gehen und damit langsamer laufen, sie sind aber eindeutig schneller !!!
Der embedded SQL geht an die PF, würde also die SQE gehen, läuft aber langsamer.

Nur zur Richtigstellung:
1. Eine View hat zwar das Datei-Attribut LF wird vom Query Optimizer bzw. Query Dispatcher anders behandelt als eine DDS beschriebene logische Datei.
Die Verwendung einer View in einem SQL-Statement bewirkt kein Rerouting an die CQE. Wird eine logische Datei in einem SQL-Statement verwendet, erfolgt die Ausführung durch die CQE. Aus der logischen Datei werden nur die Feld-Auswahl, die Select/Omit-Anweisungen und Join-Informationen Datei entnommen und das SQL-Statement entsprechend umgeschrieben. Im zweiten Schritt werden dann die benötigten Zugriffs-Wege ermittelt. Wenn die gleiche logische Datei, die auch im SQL Statement als Zugriffs-Weg verwendet wird, ist das nur ein Zufall.
2. Ob die SQE für physische Dateien zum Zug kommt, hängt u.a. davon ab, ob auf der physischen Datei logische Dateien mit SELECT/OMIT-Anweisungen liegen. In diesem Fall wird das SQL-Statement von der CQE ausgeführt.
3. Weiterhin gibt es sehr wohl Unterschiede, ob eine Datei mit SQL oder DDS definiert wurde. (außer REUSEDLT*YES). So erfolgt bei SQL beschriebenen Tabellen die Gültigkeits-Prüfung erst beim Schreiben (unabhängig, ob mit SQL oder native I/O), während bei DDS beschriebenen Dateien die Validierung beim Lesen erfolgt.

Birgitta

[Fuerchau]

@Birgitta
Aussage 3 verstehe ich nun überhaupt nicht mehr !
Prüfung beim Lesen und nicht beim Schreiben ?
Welchen Sinn sollte das denn machen, dann würde ich ja beim Schreiben ungültige Daten wegschreiben können (was nachweislich z.B. bei Datum-Typen nicht geht) ?!

[B.Hauser]

@Birgitta
Aussage 3 verstehe ich nun überhaupt nicht mehr !
Prüfung beim Lesen und nicht beim Schreiben ?
Welchen Sinn sollte das denn machen, dann würde ich ja beim Schreiben ungültige Daten wegschreiben können (was nachweislich z.B. bei Datum-Typen nicht geht) ?!

Mach mal folgendes Beispiel:
1. Datei mit CRTPF und fester Satz-Länge.
2. In diese Datei füllst Du irgendwelche alphanumerischen Daten.
3. Erstelle eine DDS-beschriebene Datei mit einem (oder mehreren numerischen Feldern)
4. Kopiere Datei 1 mit CPYF und FMTOPT *NOCHK in die DDS beschriebene Datei.
5. Mit WRKF wirst Du feststellen, dass der (oder die) Datensätze anstandslos übernommen wurden.

6. Jetzt erstelle die gleiche physische Datei (mit den numerischen Feldern) mit CREATE TABLE.
7. Kopiere Datei1 in diese mit SQL erstellte Datei (wieder mit CPYF und FMTOPT*NOCHK),
8. Jetzt wirst Du feststellen, dass kein Datensatz mit ungültigen Daten in die Datei übernommen wurde.
9. Alternativ kannst Du auch das Joblog prüfen.

Das sind so kleine Unterschiede zwischen DDS und SQL beschriebenen Dateien, die aber bis zu 40% Performance-Steigerungen mit sich bringen können, da in einer herkömmlichen Anwendungen weit mehr Lese- als Schreib-Operationen erfolgen. Die sonstigen Prüfungen, auf die Du anspielst, werden z.B. von RPG druchgeführt.

Welchen Sinn das Ganze macht, und warum das so ist, kann ich nicht sagen. Der Grund dafür wird wohl sein, für alte (/36 oder noch älter) Anwendungen eine Prüfung der Daten beim Einlesen der Daten erfolgen musste um Dezimal-Datenfehler u.ä. zu vermeiden, während die andere Vorgehensweise im SQL-Standard definiert ist.

Wer gerne mehr darüber wissen möchte, findet in der iNN - eNews vom Juni einen aktuellen Artikel von Dan Cruikshank:
Performance Comparison of DDS-Defined Files and SQL-Defined Files

Birgitta

[Fuerchau]

Ja OK, den guten alten LVLCHK habe ich nicht berücksichtigt.
Dieser ist nur bei DDS möglich.

Allerdings prüft das System beim Schreiben per RPG auch DDS-Dateien, wenn LVLCHK aus ist.

Beim Lesen solcher kaputter Dateien, gibts allerdings bei RPG meist keinen Fehler, da Dezimalfehler ignoriert werden.
Beim ILE gibts dann wiederum trotzdem Fehler, wenn nicht explizit FIXNBR angegeben ist.

Wenn ich denn dann die DDS-PF per SQL bearbeite erfolgt auch beim Schreiben die Typprüfung.

Sicherlich ist beim Lesen der DDS-PF für SQL immer eine Typprüfung erforderlich. Dies kann aber nicht obiges Problem sein, da die PF ja DDS-beschrieben ist und somit SQL über die View als auch über die PF eine Typprüfung machen müsste.

Allerdings konnte ich bisher keinen nennenswerten oder performancerelevanten Unterschied zwischen DDS und SQL-Dateien feststellen (auch bei Dateien mit mehr als 10.000.000 Sätzen, DDS-beschrieben).
Die Performance konnte immer durch gezielte Erstellungen von Indizees massiv beeinflusst werden !

[Robi]

So, umfangreiche Tests auf unsere AS400 mit extra erstellten großen Dateien (2 mio Sätze) haben ergeben :
alles was ich geschrieben habe muß Quatsch sein.
alles was ihr geantwortet habt ist die Praxis (bei uns).
Trotzdem ist auf der KD-AS400 eine identische VIEW deutlich schneller als Sql-lesen eines PF.
Ich geb auf!
Der Kd ist zufrieden, da wir auf VIEW umgestellt haben.
Vielleicht fehlt ihm ja ein PTF, das sql-lesen wieder beschleunigt. Habe der EDV eine entsprechende Info gegeben.
Ich Danke Euch für eure Hilfe
Gruß
Robi