Zugriff mit sql wirklich schneller

[dibe]

@D*B
Ich kann die Daten nicht wirklich lesbar, und performant mit EINEM Sql verknüpfen
Dazu wären etliche Case Bedingungen zu gestalten.

Ich lese mit setll/read eine Datei durch und muß aus zig verschiedenen Datein Einzelwerte dazu holen.
Welcher Wert, mit welcher Bedingung und welche alternative bei nicht gefunden ist individuell vom Alter des Satzes und der Art des Basissatzes abhängig.

Vermutlich aus Ihrer Sicht Murks, so haben Sie sich ja schon öfter ausgedrückt.
Aber für die Aufgabe unerlässlich. Und das 'vereinheitlichen' aller Daten wäre, bei der Masse der Programme hier, ein nicht zu unterschätzender Aufwand.

Bitte lassen sie uns doch einfach die Performance
set :Feld = (select x from x where z...) VS
Setll, dou, read, if z = ... leave, enddo bei max 5 zu überlesenden Sätzen
sprechen

Und da ist, wenn ich Sie vorab richtig verstanden habe der RLA Zugriff doch schneller, da nicht der SQL Rucksack aufgebaut wird?


@Fuerchau
keine 30 Sekunden?
Ich rede von > 40 Minuten!

Danke
DiBe

[BenderD]

@Murks: ich rede gerne Klartext, das ist verständlicher und hat sich bei Schulungen und Vorträgen bewährt. Den meisten Murks findet man bereits vor, man sollte sich bemühen den Murks nicht noch größer zu machen, dafür braucht man einen geschärften Blick, was Murks ist.

Zurück zur Problemstellung:
Wenn Datensätze aus mehreren "Basisdateien" zusammengeführt werden sollen, landet man beim Union der ist niemals wirklich schnell. Für read only ist da am effektivsten die Daten im ersten Schritt in einer temporären Tabelle zu sammeln und dann auf diesen Bestand weiter zu machen.
Das zufügen von fehlenden Feldern kann man dann mit erledigen, ob man da case oder coalesce ausreicht, hängt von den Daten ab.

Wenn nichts "überlesen" wird, ist RLA schneller und vor allem Ressourcen schonender. Solange SQL nichts blocken kann (auch hinter den Kulissen) ist RLA im Vorteil.

Wenn bei euch ein Index Aufbau über 12 Mio Sätze 40 Minuten braucht, dann habt ihr - aus heutiger Sicht - ein ernsthaftes Problem: entweder völlig unzureichende Hardware oder einen Softwaredefekt oder eine völlig vermurkste Konfiguration des Systems (Subsysteme, Speicherpools...)

mfg

und nix für Ungut für das ein oder andere harte Wort

Dieter Bender

[Fuerchau]

40 Minuten steht eher noch für eine B10 mit V4R5 oder max. V5R2 als für eine neuere P-Maschine mit mindestens V7R3.
Wenn der Indexaufbau bei euch diese Performance hat, würde ich von SQL generell eher Abstand nehmen. Dann gibts wahrscheinlich noch "Classic Query Engine" statt "SQL-Query-Engine".
Und da gibts eklatante Unterschiede in der Performance.

Ich habe schon komplexere SQL's gebaut mit CTE, Derived Tables, bis 30 Tabellen und eine P7 verarbeitet da bis zu 10Mio. Zeilen pro Sekunde (Laut SQl-Analyse). Da lohnt noch nicht mal ein Index.

[dschroeder]

Dann auch noch mein Beitrag zu dem Ganzen:

Wenn wir neue Programme schreiben, machen wir die Zugriffe immer mit SQL. Wenn wir bestehende Programme modifizieren, ändern wir die Zugriffstechnik manchmal von RLA auf SQL, wenn das das Programm dadurch übersichtlicher wird und der Programmeingriff sich "lohnt".

Wir machen uns über Performance beim SQL-Zugriff wenig Gedanken. Wenn die passenden Indizes da sind, geht der Zugriff bei uns eigentlich immer so schnell, dass ich nicht glaube, dass RLA Zugriff da etwas verbessern würde.

Aber ich bin genau wie Baldur und Dieter der Meinung, dass ein Austauschen von einzelnen READ oder CHAIN durch eine SQL-Anweisung performancemäßig nichts bringt. Das heißt, wenn eure Leseschleifen mit READ / SETLL usw. jetzt optimiert sind und ihr strukturell am Programm nichts ändern wollt, dann würde ich die Zugriffe auch nicht durch SQL ersetzen.

SQL entwickelt seine Stärke in der Performance, wenn man mengenorientiert arbeiten kann.

Eine Indexerstellungszeit von 40 Minuten finde ich auch sehr viel. Ich denke, ein Index, der aus ein paar Feldern besteht, würde bei 12 Mio Datensätzen bei uns in nicht mehr als 1 Minute erstellt. Ist mir schon klar, dass dir diese Aussage jetzt nicht viel nützt, wenn du ein anderes System hast.

Aber du wolltest ja wissen, wie andere das so handhaben.

Ich wollte mit meinen Aussagen im wesentlichen nur sagen, dass wir beim Einsatz von SQL normalerweise keine Performanceprobleme haben und noch nie auf die Idee gekommen sind, dass wir RLA einsetzen müssen, damit es performant wird.

Allerdings hatten wir beim Umstieg auf 7.5 einen Bug im SQL-Optimizer. Da wurden einige SQL-Statements extrem langsam. Das konnte / musste IBM mit einem PTF lösen. Es lag, glaube ich, daran, dass der Plan Cache nicht benutzt wurde und jedes Statement jedes mal den vollen Optimizerprozess durchlief.

Deshalb sollte man bei extrem langsamen Zugriffen nicht ganz ausschließen, dass es auch mal an IBM liegen kann!

LG, Dieter

[dibe]

Danke,
ich werde nun mal jemanden suchen, der mir das analysiert, warum das so extrem langsam ist.
(2. Pgm Version mit RLA dauert auch ewig,
Und das ist eigendlich ein sehr einfacher Code)

Danke Euch, ggf berichte ich!

Dietlinde Beck

[dschroeder]

Nur eine Idee: Habt ihr in eurer Tabelle vielleicht extrem viele gelöschte Sätze drinstehen? Dann müsste man mal ein RGZPFM machen. Wenn man sich das nicht "traut", weil man nicht weiß, wie lange es dauert,
könnte man die Tabelle vielleicht auch mal testweise erstmal umkopieren.

[Fuerchau]

Zu obigem Hinweis:
Eine PF hat die Eigenschaft "ReuseDlt" um gelöschte Sätze mit neuen zu überschreiben.
Bei TABLE's, also SQL, ist der Default YES, bei PF's leider NO.
Wenn man die Eingangsfolge benötigt, sollte man dies über einen Timestamp oder neu, eine Identity-Column lösen, da der RGZPFM durch Angabe einer LF auch in Sortierfolge der LF umsortieren kann.

Bei deinen o.a. 40 Minuten für den Index schätze ich mal 12 Mio. aktive Sätze und mehrere 100 Mio. gelöschte Sätze.

Nach dem RGZPFM kann ein CHGPF ... REUSEDLT(*YES) nicht schaden.

[BenderD]

Danke,
ich werde nun mal jemanden suchen, der mir das analysiert, warum das so extrem langsam ist.
(2. Pgm Version mit RLA dauert auch ewig,
Und das ist eigendlich ein sehr einfacher Code)

Danke Euch, ggf berichte ich!

Dietlinde Beck

-- was habt ihr denn an Hardware, Release- und PTF-Stand?

[Robi]

Moin zusammen
ich habe mich da mal drauf geschaltet und mir das Thema mal angesehen.

@LF und 40 Minuten
Das LF hat zwar einen 'normalen' Namen, ist aber kein 'normales' LF
Es ist ein LF in dem 4 Dateien mit insgesamt > 234 Mio Sätzen zusammen gefasst sind.

Sein Name entspricht den Namensregeln einer einfachen LF, daher das Missverständnis.
Reuse ist i.d.R Verwendet, gelöscht wird (in der Anwendung) nie!


@Performance
Einer der SQL Zugriffe hat eine Schnittstellen Datei gelesen.
Der Schnittstellenpartner hat wohl Vorgaben gemacht, welche Art und welcher Länge die Felder haben sollen.
So haben 2 (Key) Felder die Definition 25A
Die zugriff Felder aus der Anwendung sind aber 7P 0 bzw 1S 0

In der Umwandlung sieht man, das die SQL generierten Felder dehnen aus der Anwendung entsprechen
(SQL_0156 7P0, SQL_0157 1S0)

Codiert war
insert into ... from ...where Feld_25A_1=:Feld_7P0 and Feld_25A_2 = :Feld1S0
Im Debug merkt man nicht, das das dauert (anders als z.b. ein clear auf eine grosse Feldgruppe)
Nach der Anpassung das auf 25A mit 25A zugegriffen war das Pgm um Faktor >200 schneller

Kunde zufrieden, wieder was gelernt ...

VG
Robi

[Fuerchau]

Da kann man mal sehen, wie wichtig bei SQL-Zugriffen die korrekte Typisierung ist.
Das hilft auch schon mal in einer Join, wenn die verbundenen Felder nicht genau passen.
Z.B.: "...on cast(fromField as ..) = ToField..."