embedded-SQL fetch über mehrere Dateien

[BenderD]

... und bei Änderungen am Dateiaufbau etc. ändert sich immer nur die View und nicht das Programm (siehe auch Thread Dateiänderung ohne recompile)

mfg

Dieter Bender

Dann kann ich auch direkt mit "select * from myview" arbeiten

[B.Hauser]

Ein Recompile ist allerdings nur dann nicht erforderlich, wenn einzelne Felder ausgewählt und in einer Datenstruktur zusammengefasst wurden.

Wird eine externe Datenstruktur und SELECT * verwendet, ist ein Recompile wie bei anderen Datei-Änderungen erforderlich.

@Zannaleer
Du kannst auch folgendes versuchen:
Die einzelnen Dateien als Externe Mehrfach Datenstrukturen definieren und beim Fetch diese Datenstrukturen aufzählen.

d Ds_AAP        e ds                  extname(AAP) occurs(7)        
d Ds_AAI        e ds                  extname(AAI) occurs(7)
d Ds_AAK        e ds                  extname(AAK) occurs(7)

c/EXEC SQL  FETCH Next from MyCursor for 7 Rows
C+          into :DS_AAP, :DS_AAI, :DS_AAK
C/END-EXEC 

Diese Lösung funktionniert zumindest beim Single Row Fetch, beim Multiple Row Fetch habe ich es noch nicht probiert.

Die bessere Lösung ist allerdings eine SQL-View zu benutzen.
Dies vereinfacht nicht nur den Code, sondern ist zudem auch noch performanter als ein direkter JOIN im Programm.

Birgitta

[BenderD]

Hallo,

sorry, Einspruch in zwei Punkten:
1. wenn die View dasselbe Format liefert, dann ist es völlig Wurscht wo die Daten wirklich herkommen, dann brauchts kein Recompile! Sprich: man ändert eventuell im View Layer und nicht das Programm.
2. Ob ich eine View habe, oder einen Join mache, das ist von der Performance her Banane. Die (SQL) View hat keinen Zugriffspfad und enthält auch keinen Zugriffsplan, der kann erst bei dem Select im Programm berechnet werden, da hier ja auch noch eine Order By Klausel stehen kann!

mfg

Dieter Bender

Ein Recompile ist allerdings nur dann nicht erforderlich, wenn einzelne Felder ausgewählt und in einer Datenstruktur zusammengefasst wurden.

Wird eine externe Datenstruktur und SELECT * verwendet, ist ein Recompile wie bei anderen Datei-Änderungen erforderlich.

@Zannaleer
Du kannst auch folgendes versuchen:
Die einzelnen Dateien als Externe Mehrfach Datenstrukturen definieren und beim Fetch diese Datenstrukturen aufzählen.

d Ds_AAP        e ds                  extname(AAP) occurs(7)        
d Ds_AAI        e ds                  extname(AAI) occurs(7)
d Ds_AAK        e ds                  extname(AAK) occurs(7)

c/EXEC SQL  FETCH Next from MyCursor for 7 Rows
C+          into :DS_AAP, :DS_AAI, :DS_AAK
C/END-EXEC 

Diese Lösung funktionniert zumindest beim Single Row Fetch, beim Multiple Row Fetch habe ich es noch nicht probiert.

Die bessere Lösung ist allerdings eine SQL-View zu benutzen.
Dies vereinfacht nicht nur den Code, sondern ist zudem auch noch performanter als ein direkter JOIN im Programm.

Birgitta

[B.Hauser]

1. wenn die View dasselbe Format liefert, dann ist es völlig Wurscht wo die Daten wirklich herkommen, dann brauchts kein Recompile! Sprich: man ändert eventuell im View Layer und nicht das Programm.

Vielleicht hatte ich mich unklar ausgedrückt:
Ein Recompile ist erforderlich, wenn sich die Anzahl und/oder Reihenfolge von Feldern in einer View ändert und zur Ausgabe eine externe Datenstruktur über die View verwendet wird.
Die externe Datenstruktur wird zur Compile-Zeit in das Programm/Modul-Objekt eingebunden!
Wird also eine Datei um mehrere Felder erweitert und in der View werden alle Felder verwendet (CREATE VIEW as SELECT a.*, b.* from a join b on ...) muss auch die Ausgabe-Datenstruktur verändert werden, also RECOMPILE.
Werden einzelne Felder ausgewählt (bei der Erstellung der View oder im Programm/Modul) ist ein Recompile nicht erforderlich.
Ein Recompile ist auch dann nicht erforderlich, wenn sich nur Where-Bedingungen in einer View ändern.

2. Ob ich eine View habe, oder einen Join mache, das ist von der Performance her Banane. Die (SQL) View hat keinen Zugriffspfad und enthält auch keinen Zugriffsplan, der kann erst bei dem Select im Programm berechnet werden, da hier ja auch noch eine Order By Klausel stehen kann!

Hast Du das analysiert oder erzählst Du nur was in den Büchern steht?

In der Theorie hast Du recht. Bei der Analyse (unter Release V5R2M0) von SQL-Statements über den iSeries Navigator, PRTSQLINF u.a. habe ich andere Erfahrungen gemacht.

Voraussetzung ist, dass entsprechende Indices angelegt sind und auch vom Optimizer verwendet werden.

Die langsamste Variante ist die Verwendung von DDS-beschriebenen Join-Files, da die Dateibeschreibung zunächst aufgedröselt wird, das SQL-Statement neu geschrieben wird und dann die entsprechenden Indices gesucht werden.
Soweit so klar!

Ein Join der direkt im Programm (oder auch interaktiv) ausgeführt wird ist wesentlich schneller, da meistens kein Rewrite des SQL-Statements erforderlich ist und die Indices direkt ermittelt werden können.

Wird statt des direkten Join eine SQL-View verwendet halbiert sich die Zeit. Dies ist das Ergebnis zu dem ich nach der Analyse von bestimmt schon hunderten von SQL-Statements gekommen bin.
Woran das liegt kann ich nicht sagen, in der Literatur habe ich diesbezüglich noch nichts gefunden und auch aus Rochester habe ich bisher keine Antwort zu diesem Phänomen.

Zugriffs-Pläne? Statistiken??
Es ist müsig darüber zu spekulieren, besonders, weil unter Release V5R2M0 Joins noch über die alte CQE erfolgen. In Release V5R3M0 mit der neuen SQE kann alles ganz anders und u.U. nicht unbedingt besser sein.

Und ORDER BYs sollte man eh nur verwenden wenn's nicht anders geht. Bei der Suche nach dem optimalen Index werden die Sortierfolgen sowieso erst nach Where, Join und Group By Bedingungen berücksichtigt und nicht selten wird eine temporäre Datei erstellt und über diese ein temporärer Index gelegt.

Birgitta

[BenderD]

@Birgitta:

genau das zu vermeiden ist Sinn und Zweck eines richtig eingesetzten View Layers. Ein Record Layout ist sowas, wie ein Datentyp und der ändert sich nicht!!! Wenn ich also Felder zufüge zu einer Datei, dann werden neue Views zusätzlich erstellt, in denen die zusätzlichen Felder enthalten sind und damit ändert sich für die vorhandenen nix. Wenn ich halt so blöd war meine View mit SELECT * zu erstellen, dann mache ich das bei dieser Gelegenheit dann richtig und das wars. Wer recompiles von Programmen machen muss, der macht was falsch!

Was Performance angeht, orientiere ich mich nicht an Büchern - selbst in der Reference wird gelogen, dass sich die Balken biegen (ich sage da nur neue Query Engine). So Einzelvergleiche sind immer etwas problematisch, da müsste man eigentlich hin und zurück testen, weil natürlich eine Messung die Folgemessung beeinflusst, selbst wenn das nicht im selben Job ist, da auf mehreren Ebenen gecached wird. Meine Aussagen beziehen sich auf Monitor Daten laufender Applikationen - und da immer auf die Penner, alles was schnell genug ist, ist nicht wirklich Laufzeitrelevant und interessiert mich meist nicht.
Klar ist immer, dass das Vorhandensein der entsprechenden Indices für die Joinfelder immer Voraussetung dafür ist, dass es brummt; da ich aber eigentlich immer entsprechende Constraints mit erstelle, wenn ich die Finger im Design mit drin habe, sind die automatisch da.
Mit der Order By Klausel, das kann man so pauschal nicht sagen. Wenn where Bedingungen Felder eines Teilkeys beinhalten, wirkt ein Order By nach dem gesamten Key manchmal Wunder und momentan habe ich manchmal die Befürchtung, dass das mit V5R3 noch wichtiger werden könnte, ich habe da zuweilen einen zunehmenden Hang zu Full Table Scans festgestellt.
Noch eine letzte Bemerkung zu Order By: ich kenne fast keine Anwendung, bei der einem die Reihenfolge der Daten egal ist, wenn man mehr als einen Satz hat - und dann muss Order by einfach sein!

mfg

Dieter Bender

Vielleicht hatte ich mich unklar ausgedrückt:
Ein Recompile ist erforderlich, wenn sich die Anzahl und/oder Reihenfolge von Feldern in einer View ändert und zur Ausgabe eine externe Datenstruktur über die View verwendet wird.
Die externe Datenstruktur wird zur Compile-Zeit in das Programm/Modul-Objekt eingebunden!
Wird also eine Datei um mehrere Felder erweitert und in der View werden alle Felder verwendet (CREATE VIEW as SELECT a.*, b.* from a join b on ...) muss auch die Ausgabe-Datenstruktur verändert werden, also RECOMPILE.
Werden einzelne Felder ausgewählt (bei der Erstellung der View oder im Programm/Modul) ist ein Recompile nicht erforderlich.
Ein Recompile ist auch dann nicht erforderlich, wenn sich nur Where-Bedingungen in einer View ändern.



Hast Du das analysiert oder erzählst Du nur was in den Büchern steht?

In der Theorie hast Du recht. Bei der Analyse (unter Release V5R2M0) von SQL-Statements über den iSeries Navigator, PRTSQLINF u.a. habe ich andere Erfahrungen gemacht.

Voraussetzung ist, dass entsprechende Indices angelegt sind und auch vom Optimizer verwendet werden.

Die langsamste Variante ist die Verwendung von DDS-beschriebenen Join-Files, da die Dateibeschreibung zunächst aufgedröselt wird, das SQL-Statement neu geschrieben wird und dann die entsprechenden Indices gesucht werden.
Soweit so klar!

Ein Join der direkt im Programm (oder auch interaktiv) ausgeführt wird ist wesentlich schneller, da meistens kein Rewrite des SQL-Statements erforderlich ist und die Indices direkt ermittelt werden können.

Wird statt des direkten Join eine SQL-View verwendet halbiert sich die Zeit. Dies ist das Ergebnis zu dem ich nach der Analyse von bestimmt schon hunderten von SQL-Statements gekommen bin.
Woran das liegt kann ich nicht sagen, in der Literatur habe ich diesbezüglich noch nichts gefunden und auch aus Rochester habe ich bisher keine Antwort zu diesem Phänomen.

Zugriffs-Pläne? Statistiken??
Es ist müsig darüber zu spekulieren, besonders, weil unter Release V5R2M0 Joins noch über die alte CQE erfolgen. In Release V5R3M0 mit der neuen SQE kann alles ganz anders und u.U. nicht unbedingt besser sein.

Und ORDER BYs sollte man eh nur verwenden wenn's nicht anders geht. Bei der Suche nach dem optimalen Index werden die Sortierfolgen sowieso erst nach Where, Join und Group By Bedingungen berücksichtigt und nicht selten wird eine temporäre Datei erstellt und über diese ein temporärer Index gelegt.

Birgitta