Verknüpfen von Tabellen mit SQL

[alfredo]

Sind beide Keyfelder jeweils die ersten im Key?
Sonst wäre der Vorschlag von Fuerchau sicher zielführend.
Werden sehr viele Sätze sequentiell durchgelesen?
Da ist Embedded-SQL sicher langsamer als eine Lösung mit OPNQRYF, ausser man programmiert geblocktes Lesen.
Eine Ausführung mit STRDBG schadet auf keinen Fall, da stehen immer interessante Hinweise im Joblog.

[Fuerchau]

OPNQRYF kann nicht schneller sein als SQL, da OPNQRYF SQL nutzt.

[alfredo]

Eh klar, und auch nur den alten Optimizer.
Ich habe nur das Lesen durch das Programm gemeint.
Bei OPNQRYF wird doch das Blocken unterstützt, oder liege ich falsch?

[Fuerchau]

Genau !
Im RPG bestimmt die Öffnungsart das Blocken.
I-/O-Dateien können geblockt werden, U-Daten werden nicht geblockt.

Bei SQL wird ein statischer Cursor immer geblockt.
Blocken wird verhindert bei " update of ..."

[alfredo]

War ich immer auf dem Holzweg?
Ich war der Meinung ein FETCH löst eine I/O Operation aus, die ich nur mit einem Mehrfach-Fetch in eine Datenstruktur umgehen kann?
lg

[Fuerchau]

Unabhängig davon ob du mit einem Fetch 1 Zeile oder N Zeilen abrufst, intern wird deswegen trotzdem geblockt.
Man sieht es ganz gut über "DSPJOB->Auswahl 14" (Systemanfrage 3=>14) dass die Anzahl der Leseoperationen durchaus erheblich kleiner sein kann als die Anzahl Fetch die man macht.
Blocken ist eine automatische Systemfunktion !

Anders bei native I-O. Hier wird bei RPG zusätzlicher Code ausgeführt, der das Blocken intern übernimmt.
Dadurch kommt es ja bei O-Dateien zu "seltsamen" Datenverlusten, da ggf. der interne RPG-Puffer noch nicht ausgegeben werden konnte.

[BenderD]

Hallo,

wobei natürlich ein geblockter Fetch in eine DS mit dim signifikant schneller ist...

mfg

Dieter Bender

Unabhängig davon ob du mit einem Fetch 1 Zeile oder N Zeilen abrufst, intern wird deswegen trotzdem geblockt.
Man sieht es ganz gut über "DSPJOB->Auswahl 14" (Systemanfrage 3=>14) dass die Anzahl der Leseoperationen durchaus erheblich kleiner sein kann als die Anzahl Fetch die man macht.
Blocken ist eine automatische Systemfunktion !

Anders bei native I-O. Hier wird bei RPG zusätzlicher Code ausgeführt, der das Blocken intern übernimmt.
Dadurch kommt es ja bei O-Dateien zu "seltsamen" Datenverlusten, da ggf. der interne RPG-Puffer noch nicht ausgegeben werden konnte.

[alfredo]

Von der Theorie zur Praxis:
Lesen von 1.500.000 Sätzen aus einer PF mit Order auf bestehende LF.
OPNQRYF 7.000 ms
SELECT * (25 Felder) 21.000 ms
SELECT 9 Felder 19.000 ms
Mehrfachfetch ?

Für Dialogprogramme ist das natürlich nebensächlich.
lg

[B.Hauser]

Hallo Alfredo,

wenn Du SQL z.B. mit native I/O vergleichst, evt. auch mit OPNQRYF darfst Du niemals nach der ersten Ausführung gehen.

Bei der ersten Ausführung mit SQL läuft der komplette Optimierungs-Prozess, mit Erstellung/Validierung der Access Plans, Prüfen der vorhandenen Zugriffs-Wege und Aufbau/Öffnen des verwendeten Daten Pfades (ODPs). Nach der ersten Ausführung wird der ODP wieder geschlossen. Beim zweiten Durchlauf wird der Access Plan nochmals geprüft und der ODP erneut aufgebaut. Erst nach dem zweiten Aufruf bleibt der ODP geöffnet und kann immer wieder verwendet werden. Und erst nach diesem Aufruf kann SQL mit native I/O verglichen werden. Und erst ab dem 3. Aufruf wird SQL schneller als native I/O.

Wie Dieter bereits gesagt hat ist auch das Fetchen eines einzelnen Satzes signifikat langsamer als ein Fetch in eine Mehr-Dimensionale-Datenstruktur (vor V5R3) oder in eine Array-Datenstruktur (ab V5R3). Ebenso kann durch die Angabe von FOR READ ONLY oder FOR FETCH ONLY eine Performanceverbesserung erreicht werden, da in diesem Fall auf alle Fälle geblockt gelesen wird. Select-Statement, die über Cursor verarbeitet werden und nicht von Natur aus READ ONLY sind (z.B. durch Join-Anweisungen, Order By oder Group By-Anweisungen), sind updatefähig. Diese Update-Fähigkeit verhindert u.U. ein geblocktes Lesen.

Ich weiß jetzt nicht auf welcher Basis Du Deine Tests gemacht hast, aber solltest Du die logische Datei im SQL angegeben haben, muss ein rerouting von der SQE (SQL-Quera-Engine) zur CQE (Classic Query Engine) erfolgen, was bis zu 10% Performance kosten kann. OPNQRYF dagegen kann die logische Datei direkt verarbeiten, da OPNQRYF eine alte Technolgie und kein SQL ist.

Deine Ergebnisse in Ehren, aber ohne genauere Informationen, wie die Statements aussehen, bzw. aufgerufen wurden, kann man dazu nichts sagen. Weiterhin würde ich ihnen ohne detaillierte Analyse über DBMON keinen Glauben schenken.

Birgitta

[alfredo]

Na gut:
Select * from PF
order by A,B
for fetch only

Für den Vergleich wurde jede Variante 3x hintereinander aufgerufen und der letzte Aufruf verglichen.
lg

[BenderD]

Hallo,

der Test sieht schon ok aus und die Ergebnisse entsprechen schon dem, was ich so aus eigenen Erfahrungen in Erinnerung habe; ich denke, dass ein Blockfetch von sagen wir mal 500 im SQL nochwas gut macht, aber das ist alles aus meiner Sicht nicht so ausschlaggebend. Im Dialog, ist wie du bereits angemerkt hast, das eh egal.
Was für SQL gegenüber OPNQRYF spricht, ist das einfachere Handling und die bessere Lesbarkeit, vergleiche ich Record Level Access mit den dynamischeren Varianten, dann ist es die größere Flexibilität und die im Schnitt (!!!) besseren Antwortzeiten von SQL, die daraus resultieren, dass der Programmierer sich im richtigen Leben zuweilen für die zweitbeste Lösung entscheidet.
In den Bereich des Marketings und des Wunschdenkens gehört, dass SQL per se schneller sei als Record Löffel Ekzem, letzteres ist bei entsprechender Optimierung bei über 90% der Fälle im Vorteil - apropos Wunschdenken, die SQE ist eine mittlere Katastrophe, nach jedem Database Group PTF halte ich die Luft an, was da wieder alles krumm ist und oft wird mehr langsamer als schneller wird!!!

Fazit: konsequenter Umstieg zu SQL, wegen besserer Programmierer Performance, was die Maschine angeht ist es SQL für heutige Hardware schnell genug, im Dialog liegt der Unterschied (bei entsprechendem Index Design) unter der Messbarkeits Schwelle und im Batch holt man Speed eh' über Parallelisierung zur Auslastung der vorhandenen Hardware und nicht über Hungerjobs.

mfg

Dieter Bender

Na gut:
Select * from PF
order by A,B
for fetch only

Für den Vergleich wurde jede Variante 3x hintereinander aufgerufen und der letzte Aufruf verglichen.
lg

[e_sichert]

Vielen Dank meine Herren für die detailierten Ausführungen.
Leider übersteigen diese (derzeit noch) meinen IT Horizont.

Trotzdem, nochmals vielen Dank.