-
Zitat von andreaspr@aon.at
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.
Similar Threads
-
By linguin in forum NEWSboard Programmierung
Antworten: 11
Letzter Beitrag: 10-08-17, 12:51
-
By Isabella Pridat-Zapp in forum Archiv NEWSboard Events
Antworten: 0
Letzter Beitrag: 10-09-15, 12:50
-
By Sebastian85 in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 11-03-15, 07:26
-
By B.Hauser in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 08-02-02, 17:18
-
By Frank Pusch in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 17-05-01, 09:34
Tags for this Thread
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks