Durch SQL-Trigger eine 60-fache Laufzeit des betroffenen Progamms.

[Lucky662]

... für die schnellen Antworten.

- Also ich Ändere erstmal den SYSVAL QQRYDEGREE,
- dann wandel ich die Datei in eine SQL definierte Tabelle (1:1) - caching!?
- Als nächstes kommt ON EACH STATEMENT anstelle von EACH ROW.

Gibt es noch andere Vorschläge?

Kurz zum Produktivsystem:

• System: 8286-42A
• 1 x LPAR auf dem System, Kein VIOS
• Prozessor: EPXF, 7 Core freigeschaltet
• Hauptspeicher: 512 GB
• HDD: 6200 GB mit internen Flash-Drive - Type 9 x 700 GB - Modell 59C2
• OS: V7R1 mit TR11

[Lucky662]

Diese Funktion ist eine SQL-Funktion und läuft auch (und grade da) bei dem Insert mit select von der fertig berechneten Tabelle. Ich weiß, dass ich dieses Statement am ende des CL's aufrufen kann um mir den Ärger zu ersparen.
Aber ich möchte ja auch mal History-Tabellen schaffen, die an jeder relevanten Tabelle mit einem Trigger versorgt hängen.
Wenn ein Insert-Trigger also schon solche Laufzeitverlängerungen verursacht funktioniert das nicht. Deshalb der Aufwand.

[Fuerchau]

Achtung: bei ON EACH STATEMENT must du die Daten, die gerade insertet wurden erst wieder lesen, was der Gesamtperformance eher abträglich ist, denn an deinem Insert ändert sich ja nichts.
Das Lesen "from inserted" kommt da noch dazu.
Zusätzlich muss die DB die temporäre "Inserted"-Tabelle schreiben. Also gleich doppelter Performanceverlust.

ON EACH STATEMENT lohnt sich nur, wenn man nicht für jeden Satz eine Operation durchführen muss.

Kodierst du einen einzelnen Insert, wird der Trigger 1x gerufen. Die Daten stehen in "Inserted" als Kopie und nicht in den Programmvariablen.
Kodierst du einen "insert into .... select from..." wird der Trigger wieder 1x aufgerufen.
Auch hier stehen alle Daten noch mal in "Inserted" zur Verfügung.