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