SQL Update

[andreaspr@aon.at]

ok danke, dann ist eh alles klar.
wenns sql-tabellen wären würde es nämlich auch schneller laufen.

[Fuerchau]

Dem kann ich nicht zustimmen.
Mit PF's und LF's läuft es fast immer genauso schnell wie mit SQL-Tabellen.
Wichtig sind einzig und allein vorhandene Indexe und ob sie identische Definitionen haben.
Identisch heißt hier wirklich identisch. Packed und Zoned ist dem RPG nämlich egal, der schiebt dann Umwandlungen ein, SQL aber nicht.

Manchmal ist es hilfreich, den Key auf der linken Seite per cast anzupassen, also
decimal(a.Key, n, y) = b.key
oder
zoned(a.key, n, y) = b.key

Das funktioniert auch mit ungleich langen Zeichenfeldern:
cast(a.key as char(nn)) = b.key

Und zu guter letzt:
LF's mit Select/Omit werden komplett ignoriert!
In früheren Releases führte allein die Existenz einer solchen LF zur Verwendung der CQE.

[cbe]

Hallo Robi,

ist zwar schon vorbei, aber folgendes wäre evtl. auch gegangen:

update DATEI2 a set Jahr = coalesce((select Dec(substr(datum, 1, 4)), Jahr) from DATEI1 b where a.key1 =
b.key1)

dann spart man sich den EXISTS.
(Ich mag die coalesce-Funktion einfach, vor allem wegen dem Namen...)

Gruß, Christian

[B.Hauser]

dann spart man sich den EXISTS.
(Ich mag die coalesce-Funktion einfach, vor allem wegen dem Namen...)

Gruß, Christian

@Christian
Nur solltest Du dabei berücksichtigen, dass bei der Verwendung von EXISTS nur die Datensätze, für die die Bedingung zutrifft geändert werden, während bei der Verwendung von COALESCE ALLE Datensätze geändert werden. Im Klartext heißt das, dass der Datensatz gelesen und unverändert wieder (physisch) geschrieben wird. Wenn Du also eine große Datei hast und nur wenige Sätze ändern willst, kann die Performance schon ganz schön in den Keller gehen, vor allem wenn man berücksichtigt, dass man auf Satz-Sperren (bzw. entsprechende Wartezeiten) beim Lesen von Datensätzen, die man eigentlich nicht ändern will laufen kann.

Birgitta

[B.Hauser]

@Baldur

Manchmal ist es hilfreich, den Key auf der linken Seite per cast anzupassen, also
decimal(a.Key, n, y) = b.key
oder
zoned(a.key, n, y) = b.key

Das funktioniert auch mit ungleich langen Zeichenfeldern:
cast(a.key as char(nn)) = b.key

Bringt allerdings bei Joinen von ungleichen Feldern wenig bis gar nichts! Ein Index kann (zumindest) vor Release 6.1 nur verwendet werden, wenn das Original-Feld unverändert ist. Die Verwendung von CAST oder einer skalaren Funktion bewirkt, dass das Original-Feld verändert wird. Die Länge spielt dabei keine Rolle!

Allerdings kann durch die explizite Konvertierung Einfluss darauf genommen werden kann, welche Datei "führend" verarbeitet wird und mit der anderen Datei verknüpft wird. Für die Datei, bei der die Original-Felder verwendet werden, kann ein Index verwendet werden. Für die andere Datei kann allenfalls ein Teilschlüssel verwendet werden.

Ansonsten konvertiert SQL intern selber (zumindest seit V5R3)!

Natürlich sollten z.B. in Where-Bestimmungen immer die gleichen oder compatible Datentypen verwendet werden. Wenn also z.B. das Feld Kunden-Nr. alphanumerisch ist, die Kunden-Nr. in diesem Feld jedoch numerisch ist, kann man das folgende angeben:

Where  KundeNr = 4711 

Der Datensatz wird gefunden, allerdings muss für jeden zu lesenden/vergleichenden Satz eine Konvertierung vorgenommen werden, um identische Datentypen zu vergleichen zu können, was Performance kostet.

Birgitta

[andreaspr@aon.at]

Dem kann ich nicht zustimmen.
Mit PF's und LF's läuft es fast immer genauso schnell wie mit SQL-Tabellen.
Wichtig sind einzig und allein vorhandene Indexe und ob sie identische Definitionen haben.
Identisch heißt hier wirklich identisch. Packed und Zoned ist dem RPG nämlich egal, der schiebt dann Umwandlungen ein, SQL aber nicht.

bin mir jetzt nicht sicher ob wir das gleiche meinten.
meine aussage bzgl. der geschwindigkeit bezog sich nur auf den zugriff mit sql auf sql-tabellen vs. dds-tabellen.
dass rpg dds-tabellen oft schneller verarbeiten kann als über sql ist klar.
wir haben in der firma auch oft probleme, wenn via sql auf dds-tabellen zugegriffen wird. ändere ich diese auf sql-tabellen, läuft es viel schneller.
denn im ersten fall wird die CQE verwendet und im zweiten die SQE, welche gegenüber der CQE zb auch threads parallel abarbeiten kann.

[B.Hauser]

meine aussage bzgl. der geschwindigkeit bezog sich nur auf den zugriff mit sql auf sql-tabellen vs. dds-tabellen..

Das liegt daran, dass beim Schreiben in SQL Tabellen geprüft wird, ob der angekommene Inhalt gültig ist, während beim Lesen aus SQL-Tabellen keine Gültigkeitsprüfung erfolgt. Bei DDS beschriebenen Dateien erfolgt die Gültigkeitsprüfung erst beim Lesen, während jeder Schrott in die Dateien geschrieben werden kann. Dadurch ist das Lesen aus SQL Tabellen (etwas) schneller als das Lesen aus DDS beschriebenen Dateien, während das Schreiben (etwas) langsamer ist.

dass rpg dds-tabellen oft schneller verarbeiten kann als über sql ist klar...

RPG kann zumindest bei der ersten Ausführung Dateien (unabhängig ob DDS oder SQL) schneller verarbeiten als SQL, da RPG in RPG ein Zugriffsweg vorgegeben wird (F-Bestimmungen) währen SQL grundsätzlich optimiert auch und vorallem dann wenn eine DDS beschriebene logische Datei angegeben wird.

wir haben in der firma auch oft probleme, wenn via sql auf dds-tabellen zugegriffen wird. ändere ich diese auf sql-tabellen, läuft es viel schneller.
denn im ersten fall wird die CQE verwendet und im zweiten die SQE, welche gegenüber der CQE zb auch threads parallel abarbeiten kann.

Es ist ein verbreiteter Irrtum, dass die SQE nur SQL-Tabellen verarbeiten könnte, während alle DDS Dateien von der CQE verarbeitet werden müssen. Die SQE kann DDS beschriebene physische Dateien verarbeiten.

Wird in einem SQL-Statement eine DDS beschriebene logische Datei angegeben, wird das SQL-Statement von der CQE ausgeführt, da die logische Datei aufgelöst wird (Feld-Auswahl, Select/Omit und Joins) und das SQL-Statement basierend auf der physischen Datei oder SQL Tabelle neu geschrieben wird. Dies Auflösung kann nur von der CQE vorgenommen werden (SQE steht schließlich SQL Query Engine).

Liegen auf der physischen Datei (oder SQL Tabelle) logische Dateien mit SELECT/OMIT-Anweisungen, wird auch bei Angabe der physischen Datei die Ausführung des SQL-Statements von der CQE übernommen. Der Grund dafür liegt darin, dass alle vorhandenen Zugriffswege also auch diejeningen, die in DDS beschriebenen logischen Dateien mit SELECT/OMIT hinterlegt sind verwendet werden sollen.

Ändert man in der Abfrage-Options-Datei QAQQINI die Option IGNORE_DERIVED_INDEXES auf *YES (*NO ist Unterlassungswert vor Release 6.1 mit Release 6.1 wurde der Unterlassungswert auf *YES geändert), werden Zugriffswege in DDS-beschriebenen Dateien ignoriert und das SQL-Statement kann von der SQE ausgeführt werden. Im Extremfall kann man sich durch diese Option Zugriffswege unter den Füßen wegziehen, so dass anstatt eines Index Access ein Table Scan oder zumindest eine Table Probe erfolgen muss.

Birgitta

[BenderD]

Wichtig ist immer die Größenordnungen nicht aus dem Auge zu verlieren:
- Hauptspeicheroperationen dauern < Mikrosekunden (Millionstel Sekunden), hierzu gehören Prüfungen beim lesen/schreiben
- Datenbank Operationen dauern Millisekunden (Tausendstel), hierzu gehören reads, updates, open/close
- Zugriffspfad Berechnungen dauern einige Millisekunden
- Aufbau von temporären Zugriffspfaden kann Minuten dauern

Wenn man also Minuten sucht, scheidet da einiges aus, weil es im untersuchten Fall zu selten auftritt, oder zu kurz andauert.

Im vorliegenden Beispiel sind mit hoher Wahrscheinlichkeit unterschiedliche Zugriffspläne die Hauptursache. RLA macht in jedem Fall positioned Updates (der kann nämlich nix anderes), SQL hat sich, so wie es aussieht, für searched Updates entschieden - und die sind sehr viel langsamer (typischer Wert: Faktor 2).

(Der Vollständigkeit halber sei noch angemerkt, dass alle angegebenen zeitlichen Werte von der konkreten Hardware abhängen, die Verhältnisse zueinander aber durchgängig gelten)

D*B

[andreaspr@aon.at]

hi birgitta,
danke für die aufklärung, dass beim lesen und schreiben die tabellen unterschiedlich geprüft werden wusste ich noch nicht. beiträge von dir baldur und bender sind immer eine wissensbereicherung!

lg andreas

[BenderD]

... so neu und überraschend (und so ganz richtig) ist das mit dem prüfen nicht.

überraschend nicht: DDS und RLA braucht sowas, schon wegen der Möglichkeit Multiformat Dateien zu verarbeiten

neu nicht: das war in vor SQL Zeiten generell so (Stichwort: ISAM Dateien)

so ganz richtig nicht: Konsistenzbedingungen, die beim schreiben geprüft werden gibt es auch bei DDS und RLA (Stichwort: Key Bedingungen) und ob die nahe an der Datei oder im generierten Code von RLA geprüft werden (Range Bedingungen) ist eher nicht Laufzeit relevant) SQL kann halt mehr an Konsistenzbedingungen - und geschenkt kriegt man nichts. SQL macht als streng Typ gesicherte Sprache auch beim lesen Prüfungen (typischerweise mehr als RLA!!!)

Im richtigen Leben geben sich diese Effekte in der Summe (!!!) nichts, in Einzelkonstellationen kann es da durchaus Ausreißer nach unten oder oben geben, die solche Effekte über Messbarkeitsschwellen heben.

Mein Resumee dabei:
- SQL hat in der Summe die Nase vorn, wenn ich genügend Hardware habe.
- RLA und DDS können bei Ressourcen Engpässen zuweilen noch was retten.
- Die Programmierer Performance spricht eindeutig für SQL!!!

D*B

[Fuerchau]

Ausserdem muss man bei RPG/LE noch bedenken, dass der Compiler implizit Feldprüfungen sowieso einbaut.
Dadurch, dass RPG/LE nicht direkt mit den Satzpuffern arbeitet werden intern MOVE-Befehle zwischen Datenfeld und Dateipuffer generiert.
Wenn dabei was nicht stimmt (ins besonders Dezimalfelder) gibts halt MCH-Fehler.
Auch wenn man sich die Auflösung der SQL's im Spool ansieht, sieht man eine Vielzahl von Move's, die ja auch bei Dezimalfeldern durch MI geprüft werden (dies läßt sich auch nicht abschalten).

Einzig wenn man Dateien nicht als extern, sondern intern beschrieben verarbeitet, also quasi Satz- und nicht Feldweise, kommt es bei DDS-Dateien weder beim Lesen noch beim Schreiben (Ausnahme Key's und Integritätsbedingungen) zu Fehlern, nur bei SQL-Dateien wird eben mehr geprüft.

COBOL-Leute wissen das meistens, da COBOL grundsätzlich mit den Satzpuffern direkt arbeitet.
Beim Lesen und Schreiben erfolgen nämlich keine MOVE's mehr.
Dadurch erklärt sich auch (mehr aus der Vergangenheit) die etwas bessere Performance bei Datei-IO als bei RPG/LE.

Beispiel:
Häufig werden in RPG/LE von einer Datei nicht alle Felder bearbeitet.
Man findet aber auch dann diese Kombination:

FDATEI UF E K DISK
EDATEI E DS
IDATEI

Beim Lesen werden alle Dateifelder in die DS übertragen, beim schreiben alle wieder zurück.
Läßt man die DS-Struktur weg, generiert der Compiler ausschließlich die MOVE's der verwendeten Felder (das erklärt auch, warum im Debugger ggf. Felder nicht angezeigt werden können).

Bei Massenupdates (Batch) werden eben 100.000de oder Millionen von unnötigen Moves ausgeführt um vielleicht nur 1 Feld einer Datei zu ändern.

Bei COBOL werden aber keine zusätzlichen Moves generiert, die Laufzeit ist also besser.

Man kann also unabhängig vom Dateisystem (DDS/SQL) nicht unerhebliche Performance-Verbesserungen erreichen, wenn man das berücksichtigt.

[BenderD]

... das Alter erzieht da zu Pessismismus: ich habe im Verlaufe meines Berufslebens zuviele Programme gesehen, wo der Programmierer vor lauter Performance Optimierung die Stellen übersehen hat, wo er/sie das 10 fache wieder weggegeben hat, was er wo anders mit Mühe eingespart hat. Wer da Ideen braucht, wie man sowas macht:
- sequentielles lesen gelöschter Sätze
- Hundertfach denselben Satz lesen
- update von Hunderttausenden ungeänderter Sätze
- Millionenfaches Konvertieren des heutigen Datums
- weitere Ideen findet man in historisch geschrumpften Anwendungen

Konsequenz: simple ist meist gut!

D*B

Man kann also unabhängig vom Dateisystem (DDS/SQL) nicht unerhebliche Performance-Verbesserungen erreichen, wenn man das berücksichtigt.