Verknüpfen von Tabellen mit SQL

[e_sichert]

Hallo Forum,

ich habe da ein generelles Problem mit Tabellenverknüpfungen per SQL.

Ich habe 2 Tabellen die beide ein Schlüsselfeld Auftragsnummer und ein Schlüsselfeld Auftragsposition haben.
D.h. der Key in der DDS Beschreibung der Dateien ist Auftragsnummer/Auftragsposition UNIQUE
.
Wenn ich nun die beiden Tabellen mit Select * From Tabelle1 T1 Left Outer Join Tabelle2 T2 ON T1.Nr = T2.Nr AND T1.Pos = T2.Pos

verknüpfe dauert die Ausführung des SQL's sehr lange.
Kennt jemand eine Möglichkeit die Tabellen so zu verknüpfen das die Ausführung des SQL's schneller geht.

Es ist vielleicht noch zu erwähnen das in Tabelle1 eher wenige Sätze und in Tabelle2 sehr viele Sätze sind.

Vielen Dank für die Hilfe.

[Fuerchau]

Lege über beide TAbellen einen Index mit NR und POS an. Dieser fehlt hier anscheinend.

[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