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

[Fuerchau]

Before-Trigger => du hast noch die Chance (falls erlaubt bei externen Triggern) Daten zu manipulieren um Constraints zu befriedigen (setzen Primary Key, Laden Fremdschlüssel, u.ä.)
After-Trigger => wird erst aufgerufen, wenn alle Contraints (Unique Key/Index, Not Null,Check, Ref ...) positiv beschieden sind. Eine Änderung der Daten ist nicht mehr zugelassen.

Beim SQL-Server hat man da eben keine Chance, deshalb wird dort häufig der Einsatz von Prozeduren für Insert/Update empfohlen. Was allerdings nicht unerheblichen Mehraufwand bedeutet und die Unterstützung von EF erschwert.
Wird beim After-trigger dann doch noch ein Update gemacht, wird dann bei tatsächlichen Änderungen des aktuellen Satzes noch die "Satzversionen" für die Transaktionen aktiviert werden.
Häufig wird dann auch noch vergessen, dass ja durchaus mehr als 1 Zeile betroffen wurde.

[Lucky662]

...dieses Detailproblem lässt sich auch mit einer Umsetzungstabelle und Views lösen.
Zentral wäre für mich allerdings zuerst die massive Stundendifferenz zu verstehen, bevor man versucht im nachgelagerten Bereich zu optimieren.

D*B

Danke BenderD,
dass ist das was ich verstehen will.
Warum läuft der Insert über ein select mit Umsetzung des Datums und der Uhrzeit über die Funktion in 16 Minuten durch und der Insert über den Trigger ohne Umsetzung des Datums mit Uhrzeit (also die Funktion wird definitiv nicht aufgerufen) verlängert die Laufzeit des RPG-Programms von 12 Min auf ein Vielfaches.Das Verstehe ich nicht. Wenn wir hier über doppelte Laufzeiten reden würden oder auch die Summe von 12+16Min., also von mir aus 30Minuten, dann wäre das noch nachvollziehbar aber so?
Andreas

[BenderD]

Danke BenderD,
dass ist das was ich verstehen will.
Warum läuft der Insert über ein select mit Umsetzung des Datums und der Uhrzeit über die Funktion in 16 Minuten durch und der Insert über den Trigger ohne Umsetzung des Datums mit Uhrzeit (also die Funktion wird definitiv nicht aufgerufen) verlängert die Laufzeit des RPG-Programms von 12 Min auf ein Vielfaches.Das Verstehe ich nicht. Wenn wir hier über doppelte Laufzeiten reden würden oder auch die Summe von 12+16Min., also von mir aus 30Minuten, dann wäre das noch nachvollziehbar aber so?
Andreas

... der Trigger läuft satzweise, der insert select ist eine Bulk Operation, ersteres ohne write cache, zweites mit write cache.
Bulk Operationen sind schnell, aber fatal, wenn das abkackt.

D*B

[Lucky662]

Also wenn ich die Beschreibung richtig interpretiere bedeutet *NONE: Das System verwaltet den Zeitpunkt des Schreibens.

[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.