Commit ausschalten, Fehler

[dibe]

Liebe Helfende,
unsere Anwendung ist, wie vermutlich die meißten iSeries Anwendungen 'gewachsen'.
Der Ursprung ist die /36, dann /38 und schließlich /400.
Monotitische riesengrosse Programme, die alles machen, das war der Anfang. Und die DB hatte so die ein oder andere Redundanz, 'weil es einfacher / schneller' war.
Kurz danach kamen /copy für wiederkerenden Programmcode. Auch Call war mal, aus performance Gründen nicht gewünscht, viele werden sich noch daran erinnern. Ich weis nicht, warum bei uns kein Commit eingesetzt wurde, aber ich bin sicher das die damaligen Platz und performance Probleme mit verantwortlich sind.
Das 'modernisieren' dieser ehemaligen Sünden ist schrittweise verhältnismäßig einfach möglich.
Intern beschriebenen Dateien wurden 'in einem Kraftakt' auf extern umgestellt. Bildschirm Verarbeitung vom Zyklus befreit. '/copy' in 'call' umgemünst und vieles anderes, größtenteils Schritt für Schritt, nebenbei. Dabei wurden Fehler gemacht und einige Wochenenden verbraucht. Comit wurde, und das meine ich ernst, bisher nicht gebraucht. Und der Aufwand, dies in die alte Anwendung ein zu bauen, wäre imens! Daten Journalisieren wir (teilweise). Aber nie um 'transaktionen' zurück zu drehen, das konnte die Software, in der von uns benötigten Form, schon immer.

Ich hoffe weiterhin auf eure Unterstützung wenn wir mal wieder ein Problem haben, viele Dank!
Dietlinde Beck

PS: Das gilt auch für Herrn Bender, der mit seiner manchmal etwas deftigen Art uns schon oft erheitert hat. Aber irgend jemand muß ja alles besser können, sonst könnte man ja niemanden mehr fragen.

[Fuerchau]

Nun, was die MongoDB und ähnliche Datenbanken angeht, so unterscheiden diese sich nur in der Speicherungsform eines Dokuments (= Zeile).
Für die Abfrageoptimierung müssen trotzdem Indizes erstellt werden, Join-Beziehungen, also Relationen, sind dort genau so möglich und auch nötig.
Auch wenn man dokumentenbasiert speichert, ist das Prinzip der Abfragetechnik zwischen relationalen DB's und Dokumenten-DB's identisch.
Dass Dokumente beliebige Schlüssel-/Wertpaare aufweisen, bedeutet doch nichts anderes, als das nicht vorhandenen Werte zu Schlüsseln wie in der relationalen Welt auch, als NULL-Ergebnis bewertet werden.
Die Speicherungsform als typlose Daten, also egal ob Zeichen oder Zahlen oder Subdukumente als XML/JSON ist bei Aggregation wiederum kontraproduktiv, da hier erst Umformatierungen von Zeichen in Zahlen erfolgen müssen und das kostet Rechenzeit. Dies mag marginal erscheinen, aber Millionen von unnötigen Berechnungen drücken sich letztendlich auch in Sekunden aus.

Wie in einem anderen Thread schon mal beschrieben, habe ich für statistische Zwecke eine relationale Tabelle mit Voraggregaten auf der IBM i erstellt. Dieser Job auf einer P9 lief zwar knapp 3 Stunden, produzierte allerdings ca. 100 Millionen Ergebniszeilen mit mehreren 100-Millionen Abfragen auf anderen Tabellen.
Ich bezweifle, dass andere Datenbanken dies ohne massive Parallelisierung über diverse Server (Skalierungen) mit entsprechendem Verwaltungsoverhead hinbekommen.

Auch die Erweiterbarkeit der DB2 for i lässt keine Wünsche offen.
Solange man (wie bei anderen DB's auch) sich ausschließlich im SQL-Bereich aufhält, lassen sich Tabellen jederzeit erweitern, mittels View und Instead-Of-Triggern sogar programmneutral vollkommen umbauen.
Für ERP-Zwecke ist eine relationale Datenbank wie die DB2 for i, in meinen Augen, unschlagbar.

Übrigens:
NoSQL steht für "Not only SQL". Dies sieht man dann auch an den Abfragekonstrukten, die zwar nicht wie SQL aussehen, sich aber 1:1 in SQL umsetzen lassen.

[Andreas_Prouza]

Ich weis nicht, warum bei uns kein Commit eingesetzt wurde, aber ich bin sicher das die damaligen Platz und performance Probleme mit verantwortlich sind.

Hier hat Dieter schon richtig gesagt, dass Performance kein Nachteil bei Commit ist sondern vielmehr ein Vorteil.
Die Gründe liegen meist darin, dass es einfacher war auf die schnelle ein Programm zu entwickeln und sich kein Konzept für Commitment Control überlegen musste.
* Dauer der Satzsperren
* Wer darf wann ein COMMIT bzw. ROLLBACK durchführen
usw.

Am Besten sieht man es wenn man 100.000 INSERT INTOs absetzt.
Ohne Commit 40-50 Sekunden
Mit Commit ein paar Sekunden.

[BenderD]

Comit wurde, und das meine ich ernst, bisher nicht gebraucht. Und der Aufwand, dies in die alte Anwendung ein zu bauen, wäre imens! Daten Journalisieren wir (teilweise). Aber nie um 'transaktionen' zurück zu drehen, das konnte die Software, in der von uns benötigten Form, schon immer.

Commit ist nicht nur Transaktionssteuerung sondern steuert auch die Satzsperren beim Einsatz von SQL und SQL Programmierung ist mit Commit wesentlich einfacher als ohne. Wenn Programme mit commitlevel *none gewandelt werden, werden bei SQL Operationen ohne cursor Sätze nicht gesperrt, was beim Vergleich record level access mit SQL Probleme schafft. Ersetze ich chain / update durch select into / update, kann der Satz bei der SQL Variante zwischen lesen und update von anderen Benutzern geändert werden, was nicht gewollt sein kann.
Nun gibt es (fast) immer mehrere Wege nach Rom, commit ist hierbei der einfachste!
- Programme mit commitlevel *change (ist eh' default) wandeln, select into mit Sperrlevel repeatable read (kann man beim Statement mit with Klausel angeben), zur Freigabe der Sperre commit. Der gesamte Bereich der vorhandenen Anwendung ist davon nicht betroffen, für alles, was mit RLA gemacht wird, ändert sich nichts.
Was sich ändert ist, dass die betreffenden Dateien journalisiert werden müssen, was ich ohnehin für alle Dateien empfehlen würde - das ist bei jeglicher Fehlersuche Gold wert.

D*B

PS: noch etwas zu meiner "Art": es gibt keine dummen Fragen, sondern nur dumme Antworten, vielleicht sollte ich den Adressaten kritisch scharfer Antworten künftig deutlicher benennen. In dem Sinne entschudige ich mich bei dibe.