Anzahl der Host-Variablen geringer als die Ergebniswerte.

[BenderD]

Tja, da zeigt sich mal wie immer: Man muss wissen was man tut;-).
Einen Performanceunterschied zwischen Select * und Select f1, f2 ... konnte ich bisher nicht feststellen.
Der interne DB-Read liest sowieso den ganzen Satz und die SQL-Runtime macht dann nur noch ein paar Moves. Bei sinnvoller Verwendung von "DataPointern" (Zeiger auf Daten mit Feldspezifikation) werden die das wohl sinnvoll implementiert haben. Auch im RPG findet man dann nur Moves.
Und Millionen von Moves sind immer noch schneller als 1000de von Read's.

Anders siehts tatsächlich bei remoten DB's aus, da ich gezielt durch Angabe der Felder weniger Daten übertragen muss.

Und was den Join-Quatsch angeht.
Selbst da könnte ich einen "Select a.* from a inner join b on ..." durchaus machen, wobei da ein "where exists " durchaus sinnvoller ist.

... bei remote Verarbeitung werden niciht nur Daten, sondern auch die Statements übertragen!!!
Ich erinnere mich da an einen Kunden, der von "Experten" beraten wurde und denen man eine "Modernisierung" verkauft hat. Da wurden alle Quellen mit Tools nach total free RPG konvertiert, anschließend hat man sich nicht getraut das auch zu wandeln und in Produktion zu setzen und festgelegt das bis zur jeweils nächsten Änderung eines Programms zu verschieben. Dann hat man alle DDS erstellten Dateien nach SQL beschriebenen umgesetzt und dabei Autoincrement keys, und Timestamps für Anlage und Änderung zugefügt, sowie alle Feldnamen sprechend gemacht und gravierend verlängert. Da alle Programme mit RLA zugreifen, hat man anschließend die alten DDS LFs wieder draufgesetzt und alle Keybeziehungen, wie vorher wieder hergestellt.
Anschließend wollte man die Datenbank dann auf einen MS SQL-Server verschieben. Select * war dabei genauso verboten, wie die Erstellung "unnötiger" Views. Im proof of concept zeigte sich dann, das die Übertragung der überlangen SQL Statements mehr ausbremste, als eventuell unnötige Felder.

Gegen das Weglassen nicht benötigter Felder ist nichts einzuwenden (oft sind in Dateien mehr nie sinnvoll gefüllter Felder als tatsächlich benutzter), dann aber per View mit Select * und externen Datenstrukturen.

D*B

[Fuerchau]

Wenn man wiederholbare SQL's mit Parametermarkern ausführt, gerade bei Update/Inserts werden nur noch Daten statt Statements übertragen.
Aktuelle bin ich gerade bei einer ETL-Optimierung.
Da wird aus einer AS/400-DB mit 240Mio. Zeilen eine Select mit Ergebnis 65Mio Zeilen in einen SQL-Server gschoben. Dies dauert ca. 1 Stunde, macht 18.000 Inserts/Sekunde.
Da dies zu lange dauert, hat man bei einer "Analyse" festgestellt:
- Der SQL-Server hat fast nichts zu tun und wartet auf die AS/400
- Die AS/400-QZDASOINIT-Jobs stehen fast nur auf TIMW, warten also auf Anforderungen vom SQL-Server.

Ich habe da nun ein C#-Programm gemacht, dass diese 65Mio. Zeilen mit ca. 98.000 Zeilen/Sekunde abholt. Somit wäre ich nach knapp 11 Minuten fertig mit dem Download.

Antwort von der Microsoft-Truppe:
Ich weiß nicht was sie da machen und kann das nicht verifizieren. Unsere Seite hat ein Microsoft-Spezialist untersucht und keine Beanstandungen gefunden. Folglich muss es an der Bereitstellung der AS/400 liegen!
Das ist nun Fakt, also machen Sie die AS/400 schneller.

Was soll ich denn schneller machen, wenn das ETL-Programm (SSIS) einfach nicht schneller kann?
Ich bin schon am überlegen, ob man nicht eine CSV auf der AS/400 erstellt (geht ja fix) und dann mit 1GBit auf den Windows-Server schiebt. Dann können die vielleicht einen BulkLoad mit SSIS machen und in Summe wäre das vielleicht noch schneller.

Denn mit meinem C#.Progrämmchen rufe ich auch den Bulkload auf und konnte auf meinem langsamen Laptop bereits 23.000 Zeilen/Sekunde importieren. Was muss da wohl ein SQL-Server mit BulkLoad schaffen...
Aber ein SQl-Server zum Beweis wird nicht zur Verfügung gestellt.

Noch ein Nachsatz: Wir haben das Problem bereits seit 1,5 Jahren und seitens IBM ist keine Verbesserung eingetreten.

Ich kann da nur sagen: Eindeutig (mal wieder) ein massives Problem vor dem Bildchirm.

[Andreas_Prouza]

Es ist schon richtig: Bei sehr performanceintensiven abfragen, verwende ich auch kein SELECT * sondern wähle wenn möglich nur jene Spalten aus, die benötigt werden.
Dadurch kann ich mir, mit entsprechenden Index, einen Zugriff auf die Tabelle sparen und er liest nur den Index, da dieser eventuell alle Informationen schon beinhaltet.

Klar, bei einem 0815 SQL verwende ich auch ein SELECT * mit EXT DS.
Wenn es aber darum geht zeitkritische Abfragen zu beschleunigen, ist das sehr wohl ein Punkt (von mehreren) der in Betracht gezogen werden muss.

[BenderD]

Es ist schon richtig: Bei sehr performanceintensiven abfragen, verwende ich auch kein SELECT * sondern wähle wenn möglich nur jene Spalten aus, die benötigt werden.
Dadurch kann ich mir, mit entsprechenden Index, einen Zugriff auf die Tabelle sparen und er liest nur den Index, da dieser eventuell alle Informationen schon beinhaltet.

Klar, bei einem 0815 SQL verwende ich auch ein SELECT * mit EXT DS.
Wenn es aber darum geht zeitkritische Abfragen zu beschleunigen, ist das sehr wohl ein Punkt (von mehreren) der in Betracht gezogen werden muss.

... was soll denn bei einem select Feldliste schneller sein als ein Select * auf eine View mit derselben Feldliste?

[Andreas_Prouza]

... was soll denn bei einem select Feldliste schneller sein als ein Select * auf eine View mit derselben Feldliste?

Hab ich denn irgendwo erwähnt, dass man keine View verwenden kann ;-)
Ich bezog mich auf den Zugriff auf die Tabelle. Unabhängig ob jetzt vom Programm oder einer View aus.

[BenderD]

Hab ich denn irgendwo erwähnt, dass man keine View verwenden kann ;-)
Ich bezog mich auf den Zugriff auf die Tabelle. Unabhängig ob jetzt vom Programm oder einer View aus.

... lies doch dein eigenes Statement noch mal, (verwende ich kein select *)

[Andreas_Prouza]

... lies doch dein eigenes Statement noch mal, (verwende ich kein select *)

ja, steht da irgendwo geschrieben: Aber bitte keine View?!
Deshalb hab ich bei meinem vorherigen Post extra erklärt, dass ich mich auf die Zugriffe auf die Physische bezogen habe. Da bei der zuvor geführten Diskussion man herauslesen könnte, dass ein SELECT * auf eine Tabelle keinen negativen Einfluss auf die Performance haben soll.
Ich hoffe damit mich auch für dich verständlich ausgedrückt zu haben, dass es mir hier auf den endgültigen Zugriff auf die Tabelle geht und nicht von wo aus dieser Zugriff kommt.

[Fuerchau]

Wie gesagt: lokal ist die Anzahl Felder einer Tabelle für den physischen Zugriff auf dieselbe nicht relavant.
Von der Platte wird ein Block in den FileControlBlock (FCB) gelesen, in dem der komplette Satz in aller Schönheit steht. Nun bedarf es nur noch der Moves aus dem Block in die einzelnen Felder, wobei hier SQL erst mal eigene Felder generiert und im RPGCode noch mal in die Variablen übertragen wird.
Ob man nun 1 Feld oder die max. möglichen 8000 Felder einer PF bewegt liegt unterhalb von Nanosekunden. Die Plattenzugriffe sind da viel entscheidender bevor die Übergabe an das Programm passiert.

Ein FCB kann mehr als 1 Zeile enthalten, so dass der nächste Read nur den Pointer verschiebt.

[Andreas_Prouza]

Wenn du z.B. folgendes SQL hast:
SELECT STADT FROM CITY WHERE PLZ = 2000
Und es gibt einen Index mit den Key-Felder PLZ und STADT, dann liest die DB lediglich den Index und erspart sich den Weg zur Physischen Tabelle um die restlichen Spalten zu ermitteln.
Das wird als INDEX ACCESS ONLY bezeichnet.
Das spart viel Zeit im Zuge des Zugriffplans.

[Fuerchau]

Ja, aber wer nimmt schon mal mehr als ein paar Felder in den Index?
Ich käme nun nicht auf die Idee, wenn ich die Adresse zu einer Kunden-Nr. brauche, auch noch alle Adressfelder in den Key zu packen.
Aber das ist eher alles eine Designfrage.
Der SQL-Server kennt da z.B. einen Clustered-Index und das ist bereits die 1. Satzebene. Den kann es aber nur 1x geben.

Index-Only verwende ich da eher für (not) Exists-Abfragen, denn da werden Datenfelder i.d.R. nicht benötigt. Das ist schneller als ein Inner Join ohne Felder aus dem Join zu verwenden (s.o.).

[Andreas_Prouza]

Ja genau, es ist eine Designfrage.
Man braucht nicht immer alle Felder und wenn man bei etwas komplexeren SQLs (JOINS, Subselects, ...), wo im Zugriffsplan nur wegen einer fehlenden Spalte, die DB auf die Tabelle zugreifen muss, da diese im Index nicht vorhanden ist, dann schaut man sich an ob diese eine Spalte nicht in den Index mit hinein genommen werden kann, sodass die DB eben nicht mehr auf die Tabelle zugreifen muss und mit den Informationen aus dem Index weiter arbeiten kann.
Probier es doch einmal aus und schau dir den Zugriffsplan an.

Berücksichtigt man das nicht, schränkt man sich im Bereich Performanceoptimierung ein.
Es gibt ja viele Möglichkeiten mit der man eine Bessere Performance bekommen kann, wie MQTs, EVI, Index mit Where Bedingung, Partitionierung, das SQL selbst umzubauen uvm.

[BenderD]

Wenn du z.B. folgendes SQL hast:
SELECT STADT FROM CITY WHERE PLZ = 2000
Und es gibt einen Index mit den Key-Felder PLZ und STADT, dann liest die DB lediglich den Index und erspart sich den Weg zur Physischen Tabelle um die restlichen Spalten zu ermitteln.
Das wird als INDEX ACCESS ONLY bezeichnet.
Das spart viel Zeit im Zuge des Zugriffplans.

... schon mal was von Normalisierung gehört?