[NEWSboard IBMi Forum]
Seite 2 von 3 Erste 1 2 3 Letzte
  1. #13
    Registriert seit
    Feb 2001
    Beiträge
    18.251
    Ich habe bereits viele Insert/Update-Trigger incl. Update/Inserts korrespondierender Tabellen geschrieben ohne nennenswerte Performanceeinbussen.

    Was i.Ü. auch noch gerne vergessen wird:
    Zu DDS-Zeiten findet man noch häufig die Angabe FRCRATIO(1) in den PF's. Auch dies kann schon mal die eine oder andere Verzögerung bedeuten (Write-Cache ist abgeschaltet!).

    PS:
    ON EACH STATEMENT ist i.Ü. der Einzige Trigger bei SQL-Server.
    Die kennen nur After-Trigger und Instead-Of.
    Den Vorteil von Before-Triggern wollte ich mal diskutieren, das wurde aber überhaupt nicht verstanden.
    Die gehen lieber mit "Inserted" und "Deleted" um.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  2. #14
    Registriert seit
    Mar 2019
    Beiträge
    16
    Zitat Zitat von BenderD Beitrag anzeigen
    ...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

  3. #15
    Registriert seit
    Mar 2002
    Beiträge
    4.853
    Zitat Zitat von Lucky662 Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  4. #16
    Registriert seit
    Mar 2019
    Beiträge
    16
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Ich habe bereits viele Insert/Update-Trigger incl. Update/Inserts korrespondierender Tabellen geschrieben ohne nennenswerte Performanceeinbussen.

    Was i.Ü. auch noch gerne vergessen wird:
    Zu DDS-Zeiten findet man noch häufig die Angabe FRCRATIO(1) in den PF's. Auch dies kann schon mal die eine oder andere Verzögerung bedeuten (Write-Cache ist abgeschaltet!).

    PS:
    ON EACH STATEMENT ist i.Ü. der Einzige Trigger bei SQL-Server.
    Die kennen nur After-Trigger und Instead-Of.
    Den Vorteil von Before-Triggern wollte ich mal diskutieren, das wurde aber überhaupt nicht verstanden.
    Die gehen lieber mit "Inserted" und "Deleted" um.
    Ja, genau das habe ich auch bisher gemacht. Ich hatte nie nennenswerte Einbussen.
    Den Hinweiß auf FRCRATIO(1) werde ich auch noch nachgehen, aber wenn ich die DDS-Datei durch eine SQL-Definierte Tabelle ersetze sollte das ja auch keine Rolle mehr spielen.

    Über den Zeitpunkt der Ausführung eines Trigger habe ich mir auch schon öfter den Kopf zerbrochen, habe aber auch noch keine, nicht wiederlegbare, Antwort für befor / after gefunden.

  5. #17
    Registriert seit
    Mar 2019
    Beiträge
    16

    FRCRATIO = *NONE

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

  6. #18
    Registriert seit
    Mar 2002
    Beiträge
    4.853
    Zitat Zitat von Lucky662 Beitrag anzeigen
    Ja, genau das habe ich auch bisher gemacht. Ich hatte nie nennenswerte Einbussen.
    Den Hinweiß auf FRCRATIO(1) werde ich auch noch nachgehen, aber wenn ich die DDS-Datei durch eine SQL-Definierte Tabelle ersetze sollte das ja auch keine Rolle mehr spielen.

    Über den Zeitpunkt der Ausführung eines Trigger habe ich mir auch schon öfter den Kopf zerbrochen, habe aber auch noch keine, nicht wiederlegbare, Antwort für befor / after gefunden.
    ... den Unterschied merkt man bei cascading constraints und wenn man den laufenden update aus dem Trigger heraus modifizieren will.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  7. #19
    Registriert seit
    Feb 2001
    Beiträge
    18.251
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #20
    Registriert seit
    Mar 2019
    Beiträge
    16
    So, ich habe jetzt auf unsererm Testsystem die Zeit für die Anzahl Sätze pro Stunde aus dem ersten Programmteil (nur Insert der Schlüsselwerte und einer Differenz aus 2 Werten aus der Basisdatei) ermittelt.
    - Ohne Trigger werden hier ca. 10,8 Mio Sätze/Stunde eingefügt (6,1 Mio. in 34 Min)
    - mit Trigger werden nur 1,5 Mio Sätze/Stunde geschrieben.
    Der Insert erfolgt als 1:1 Kopie:

    create trigger MIVGES000U after insert on MIVGES00 referencing new as nnn for each row mode db2sql
    insert into ANALYSES.ANTRD0000T values(nnn.MGFIRNUM,
    nnn.MGKUNNUM,
    nnn.MGFILNUM,
    nnn.MGVERNUM,
    nnn.MGKFZNUM,
    nnn.MGKFZART,
    nnn.MGKFZGRU,
    nnn.MGBERGRU,
    nnn.MGUMSGES,
    nnn.MGUMS001,
    nnn.MGUMS002,
    nnn.MGUMS003,
    nnn.MGUMS004,
    nnn.MGUMS005,
    nnn.MGTAGGES,
    nnn.MGBERSTD,
    nnn.MGDATICO,
    nnn.MGTIMICO,
    nnn.MGDATICI,
    nnn.MGTIMICI,
    nnn.MGKILGEF);
    label on trigger MIVGES000U is 'Trigger: MIVGES00 insert';

    Die Schlüsselwerte sind nnn.MGFIRNUM, nnn.MGKUNNUM, nnn.MGFILNUM.
    nnn.MGKILGEF beinhaltet die Differenz vom Kilometerstand checkout und checkin also die gefahrenen Kilometer.
    Alle anderen Spalten sind blank oder 0, auch MGDAT* und MGTIM*, Datum und Uhrzeiten sin nummerisch definiert.

  9. #21
    Registriert seit
    Feb 2001
    Beiträge
    18.251
    Da ist es immer schwer eine Vorhersage zu machen.
    Fakt ist, dass die Anzahl der Writes sich mindestens halbieren muss, da sie ja verteilt werden.
    Nun hängt es von weiteren Faktoren ab, wie sich die IO's verteilen.
    - Satzlänge und damit die Anzahl gepufferten Writes
    - Speicherort auf dem Plattenarray (ggf. sind beide Dateien physisch auf derselben Disk)

    Aber immherhin ist das nicht Faktor 60 sondern nur 7.

    Und wie sieht die Aufgabenstellung aus?
    Muss die Kopie bei Masseninsert durchden Trigger erfolgen oder reicht ein folgender "insert into ... select from ..."?
    Letzteres kann durchaus effektiver sein, da nur blockweise gelesen werden muss während beim Insert mehrere Aktionen stattfinden:
    - Satznummer aus der Kette der gelöschten ermitteln
    - Falls keine gelöschten, ggf. Datei erweitern
    - Satz schreiben
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #22
    Registriert seit
    Mar 2002
    Beiträge
    4.853
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Da ist es immer schwer eine Vorhersage zu machen.
    Fakt ist, dass die Anzahl der Writes sich mindestens halbieren muss, da sie ja verteilt werden.
    Nun hängt es von weiteren Faktoren ab, wie sich die IO's verteilen.
    - Satzlänge und damit die Anzahl gepufferten Writes
    - Speicherort auf dem Plattenarray (ggf. sind beide Dateien physisch auf derselben Disk)

    Aber immherhin ist das nicht Faktor 60 sondern nur 7.

    Und wie sieht die Aufgabenstellung aus?
    Muss die Kopie bei Masseninsert durchden Trigger erfolgen oder reicht ein folgender "insert into ... select from ..."?
    Letzteres kann durchaus effektiver sein, da nur blockweise gelesen werden muss während beim Insert mehrere Aktionen stattfinden:
    - Satznummer aus der Kette der gelöschten ermitteln
    - Falls keine gelöschten, ggf. Datei erweitern
    - Satz schreiben
    Bulk Operationen haben unter günstigen Bedingungen einen erheblich höheren Durchsatz wie satzweise Operationen. Zur Blockung beim lesen kommen noch Blockung beim schreiben, geändertes Sperrhandling, Optimierung beim Zugriff. Der Trigger erzwingt satzweise Verarbeitung, die mit ca 500 Operationen/sec durchaus plausibel erscheint.
    Ähnliche Leistung wie bei Bulk Operationen erzielt man bei satzweiser Verarbeitung allenfalls bei massiver Parallelisierung.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #23
    Registriert seit
    Mar 2019
    Beiträge
    16

    Unhappy

    In diesem Fall reicht ein nachträglicher insert into... select from...
    Jedoch macht mir der Datendurchsatz bei den geplanten History-Tabellen Bauchschmerzen.
    Bei den einzelnen Aufträgen (Auftragserfassung/-änderung) ist das noch kein Problem, da im Max nur 2-3 Sätze hinzugefügt oder aktualisiert werden.
    Jedoch kann es auf die Fakturierung auswirkungen haben.

    Die oben genannten Werte habe ich übrigens auch schon mit den CASE WHEN... Funktionsaufrufen erreicht. Die Funktionen wurden ja durch die CASE-Bedingung nicht aufgerufen.
    CASE WHEN... hat also keine großen Auswirkungen.

    Das 60-fache war im gesamten Programmablauf aufgekommen. Hier spielt der Update-Trigger die größere Rolle, da dieser pro Satz mehrfach ausgelöst wurde (das Programm ist optimierungswürdig )
    Das 7-fache bei einem reinen Insert ohne Manipulationen ist schon nicht akzeptabel.

  12. #24
    Registriert seit
    Feb 2001
    Beiträge
    18.251
    Nun, dann kommt ggf. der Update ON EACH STATEMENT doch noch zum Tragen.
    Dann kannst du in diesem Fall den "insert ... select .... from inserted" als Bulkinsert codieren.
    Allerdings weiß ich nicht, ob durch die temporäre Inserted-Table und den dadurch zusätzlichen Write die Performance da wirklich besser ist.

    Bei deinem später noch geplanten Update wird dann auch noch die Indexoptimierung gravierend.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

Ähnliche Themen

  1. SQLRPGLE und Fehlerbehandlung zur Laufzeit
    Von linguin im Forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 10-08-17, 13:51
  2. Eine Marke, eine Halle, eine Messe: IT & Business - Ende September in Stuttgart
    Von Isabella Pridat-Zapp im Forum Archiv NEWSboard Events
    Antworten: 0
    Letzter Beitrag: 10-09-15, 13:50
  3. SQL-Trigger an PF
    Von Sebastian85 im Forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 11-03-15, 08:26
  4. Laufzeit-Probleme nach Release-Wechsel
    Von B.Hauser im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 08-02-02, 18:18
  5. Trigger / ILE RPG
    Von Frank Pusch im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 17-05-01, 10:34

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •