[NEWSboard IBMi Forum]
Seite 3 von 3 Erste ... 2 3
  1. #25
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    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

  2. #26
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Journalisierung erhöht die IO's und ändert am Blocken nichts.
    Laut Doku wird DB2ROW ignoriert und sowieso DB2SQL verwendet.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #27
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Dem mit Commit wiederspreche ich!
    Mit Commit können die IO's nachweislich verringert werden.
    Denn das System schreibt dann nach dem Commit mit Blöcken auf die Disk.
    Ohne Commit (*NONE) wird für jedes INSERT einzeln geschrieben.
    Ich würde sogar sagen, dass du mit Commitsteuerung die meiste Performance hier herausholen könntest.

  4. #28
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    Dem mit Commit wiederspreche ich!
    Mit Commit können die IO's nachweislich verringert werden.
    Denn das System schreibt dann nach dem Commit mit Blöcken auf die Disk.
    Ohne Commit (*NONE) wird für jedes INSERT einzeln geschrieben.
    Ich würde sogar sagen, dass du mit Commitsteuerung die meiste Performance hier herausholen könntest.
    ... commit bei Bulk Operationen ist fatal, da werden Millionen von Sperrren eingesammelt und beim eventuellen Rollback geht die Kiste in die Knie. Journalisierung kann durchaus positive Wirkungen haben, da dann die sequentiellen Schreiboperationen auf die Receiver vorgezogen werden, die kaum Strom kosten - wenn denn die Hardware Bilanz das zulässt.

    Im vorliegenden Fall, wenn ich denn die rudimentäre Problembeschreibung richtig verstehe, ist der Trigger das vorrangige Problem, da selbiger die Bulk Operation zur satzweisen Verarbeitung zwingt.

    Aus meinen Erfahrungen sehe ich zwei mögliche Strategien:
    - Sequenz von Bulk Operationen (hierbei sollte man prüfen, ob man für inserts alle Indexe auf delayed stellt und im nachhinein parallel wieder hochzieht - kann helfen aber auch massiv schaden)
    - Batch Änderungen massiv parallel reinfahren - dann aber mit Commit wg. Collisions.

    Generell gilt hier: es gibt keine Patentrezepte, sondern nur Arbeitshypothesen, die sorgfältig evaluiert werden müssen.

    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/

  5. #29
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Zitat Zitat von BenderD Beitrag anzeigen
    Im vorliegenden Fall, wenn ich denn die rudimentäre Problembeschreibung richtig verstehe, ist der Trigger das vorrangige Problem, da selbiger die Bulk Operation zur satzweisen Verarbeitung zwingt.
    Deshalb war mein Vorschlag die Commitsteuerung übergreifend zu aktivieren und das ATOMIC weg lassen.

    Wenn ich mit Commit um ein vielfaches schneller bin, ist die Bilanz auch im Falle eines ROLLBACK immer noch weit im grünen Bereich.

    Zitat Zitat von BenderD Beitrag anzeigen
    Generell gilt hier: es gibt keine Patentrezepte, sondern nur Arbeitshypothesen, die sorgfältig evaluiert werden müssen.
    So ist es!

    Gerade wenn es um Performance geht, ist Commit ein wichtiger Bestandteil der leider viel zu oft unterschätzt wird.

  6. #30
    Registriert seit
    Mar 2019
    Beiträge
    33
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    Deshalb war mein Vorschlag die Commitsteuerung übergreifend zu aktivieren und das ATOMIC weg lassen.

    Wenn ich mit Commit um ein vielfaches schneller bin, ist die Bilanz auch im Falle eines ROLLBACK immer noch weit im grünen Bereich.


    So ist es!

    Gerade wenn es um Performance geht, ist Commit ein wichtiger Bestandteil der leider viel zu oft unterschätzt wird.

    Der Insert-Trigger, um den es hier geht, ist ohne ATOMIC definiert. (siehe Beitrag auf Seite 2)
    Das die IBM i bei Commit direkt auf die Platte schreibt, glaub ich nicht. Soweit ich weiss entscheidet das System selbst, in welchen Blöcken, die Daten auf die Platte schreibt, es sei denn ich leite ein kontroliertes Ende ein. Wenn ich ohne Commit-Steuerung arbeite werden alle Änderungen (auch nur im Speicher) geschrieben. Dann als letztes wird die Änderung auf die Platte geschoben.
    So, wieder abgeschweift, was ich sagen will ist, wenn die Systemeinstellungen stimmen entscheidet das System über den Plattenzugriff, egal ob mit oder ohne Commit. Da ich auf unserm Testsystem diese Trigger teste, läuft auf diesem System fast nichts anderes. Sie Satzlänge beträgt 130 Byte. 64GB Arbeitsspeicher sind im System. Datentechnisch reden wir bei 6,2 Mio Sätzen von unter 1GB. Somit sollte die IBM i alles im Speicher abfackeln und dann auf die Platte auslagern. Wir reden hier schließlich nicht über PC's, die beim Abruppten beenden alles verlieren, selbst wenn ich das System zwinge sich sofort zu beenden, wird der Speicherzustand noch auf die Platte geschrieben. Somit geht auch in diesem Fall so gut wie nie etwas verloren.

    Als RPG-Entwickler weiß ich, dass ein Programm, das unter Commitment-Control läuft die Daten, egal wie viele es sind, erst festgeschriebt, wenn ich den Commit abfeuer. Beende ich das Programm vorher und starte es dann wieder, meckert das System, dass noch nicht festgeschriebene Sätze anstehen. Man muss erst ein Rollback abfeuern um die undefinierten Änderungen zu verwerfen.

    SQL arbeitet zwar beim Commit in Blöcken, aber deshalb steuert man nicht, dass das Ergebnis auf die Platte geschrieben wird. Für das System ist Arbeitsspeicher und Platte ein Speicher.
    Warum sollte IBM an diesem System, von dem Prinziep abweichen, das macht das System doch von jeher aus.

  7. #31
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Man kann sich selbst ein Testprogramm schreiben, dass 100.000 Sätze via INSERT INTO in eine Tabelle schreibt.
    Einmal mit Commit und einmal ohne.
    Ohne Commit dauert es 5 mal länger als mit.

Similar Threads

  1. SQLRPGLE und Fehlerbehandlung zur Laufzeit
    By linguin in 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
    By Isabella Pridat-Zapp in forum Archiv NEWSboard Events
    Antworten: 0
    Letzter Beitrag: 10-09-15, 13:50
  3. SQL-Trigger an PF
    By Sebastian85 in forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 11-03-15, 08:26
  4. Laufzeit-Probleme nach Release-Wechsel
    By B.Hauser in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 08-02-02, 18:18
  5. Trigger / ILE RPG
    By Frank Pusch in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 17-05-01, 10:34

Tags for this Thread

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •