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

[Fuerchau]

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.

[Lucky662]

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.

[BenderD]

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

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

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.

[Fuerchau]

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

[BenderD]

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

[Lucky662]

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.

[Fuerchau]

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.

[andreaspr@aon.at]

Vielleicht auch noch ein paar Gedanken:
* was hat die Tabelle beim Attribut REUSEDLT hinterlegt? (DSPFD)
Bei *NO wird immer am Tabellen-Ende hinzugefügt.
Bei *YES sucht er den nächsten freien Platz
* Hast du schon den DB-Monitor gestartet?
Wieviele "Hard-Open" zur Tabelle gemacht?
Falls er (aus was für einen Grund auch immer) öfters ein Hard-Open machen muss, stimmt was grundsätzlich nicht.
* Schon probiert mit Commitment Control zu arbeiten?
Also das ATOMIC weg lassen und im aufrufer Programm Commit Steuerung aktivieren.
Dann läuft der Trigger im gleichen Isolation Level wie der Aufrufer.
Hat den Vorteil dass man sich I/O ersparen kann wenn man am ende erst ein COMMIT absetzt und dadurch mit größeren Blöcken auf die Disk schreibt.
* Probier mal MODE DB2ROW statt DB2SQL

lg Andreas

[Fuerchau]

Journalisierung erhöht die IO's und ändert am Blocken nichts.
Laut Doku wird DB2ROW ignoriert und sowieso DB2SQL verwendet.